Re: CurTransactionContext freed before transaction COMMIT ???

On Tue, Oct 24, 2017 at 7:42 PM, Gaddam Sai Ram <gaddamsairam(dot)n(at)zohocorp(dot)com
> wrote:

>
> Hello people,
>
> We are implementing in-memory index. As a part of that, during
> index callbacks, under CurTransactionContext, we cache all the DMLs of a
> transaction in dlist(postgres's doubly linked list).
> We registered transaction callback, and in transaction
> pre-commit event(XACT_EVENT_PRE_COMMIT), we iterate through all cached
> DMLs(dlist) and populate in my in-memory data structure.
>
> --> For detailed explanation of our implementation, please look
> into below thread.
> https://www.postgresql.org/message-id/15f4ea99b34.
> e69a4e1b633.8937474039794097334%40zohocorp.com
>
> --> It was working fine until I was greeted with a segmentation
> fault while accessing dlist!
>
> --> On further examining I found that dlist head is not NULL
> and it is pointing to some address, but the container I extracted is
> pointing to 0x7f7f7f7f7f7f7f5f, and I was not able to access any members in
> my container.
>
> --> https://wiki.postgresql.org/wiki/Developer_FAQ#Why_
> are_my_variables_full_of_0x7f_bytes.3F
> From the above wiki, we came to a conclusion that the memory
> context in which that dlist was present was freed.
> And yes CLOBBER_FREED_MEMORY is enabled by passing
> --enable-cassert to enable asserts in my code.
>
> --> Normally the memory context inside XACT_EVENT_PRE_COMMIT is
> TopTransactionContext but in this particular case, the memory context was
> 'MessageContext'. Little unusual! Not sure why!
>
> --> So basically CurTransactionContext shouldn't get freed
> before transaction COMMIT.
> --> So what has actually happened here??? Kindly help us with
> your insights!
>
>
Can you check if CurTransactionContext is valid at that point? To see, if
this problem is related to CurTransactionContext, can you try to populate
the list in TopMemoryContext and see if that works.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com