>>>>> "Vitaly" == Vitaly V Voronov <wizard_1024@tut.by> writes:
Vitaly> #4 0x0000003d22278c80 in _int_free () from /lib64/libc.so.6
Vitaly> No symbol table info available.
Vitaly> #5 0x0000000000808887 in tuplestore_end (state=0x1794898) at tuplestore.c:455
Vitaly> i = <value optimized out>
So I may be off base here but...
Line 455 isn't anything to do with tuples; it's the BufFileClose() line.
Furthermore, there's no stack frame between the free() and the
tuplestore_end. From looking at optimized builds, this suggests that
free() has been reached via tail calls, and the only way I see that
happening is when pfree() is being called on a large allocation (one
large enough to be its own chunk), which shouldn't happen for tuples in
this example. (It can happen for the memtuples array itself.)
BufFile is a struct with a big buffer in it, though, so it'll be a large
allocation, hence the pfree() at the end of BufFileClose will end up in
free() via tail calls.
Of course the weak point in this theory is that there seems to be no
reason at all why BufFileClose could possibly get called twice ...
the only other theory would be that something has somehow reset the
memory context _before_ we got here.
--
Andrew (irc:RhodiumToad)