Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double free or corruption (!pre

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> Offhand, I find it more likely
> that some executor slot that imagines that it owns the tuple frees the
> tuple once, which is followed by a call to tuplestore_end() that frees
> the same tuple a second time (a double-free). As I mentioned, we've
> seen several bugs of that general variety in both tuplestore and
> tuplesort in the past. Some of these have been very subtle.

I see that in 9.6, nodeFunctionScan thinks it should do ExecClearTuple
on the func_slot that it's received from tuplestore_gettupleslot,
which it calls with copy = false, meaning that ExecClearTuple might be
deleting a tuple returned by tuplestore_gettuple. I wonder if this
is the same kind of issue we fixed in 90decdba3, only for tuplestore
rather than tuplesort.

tuplestore_gettuple doesn't return should_free = true unless the
tuplestore spilled to disk, so the sort of issue I'm imagining
would only arise for function results large enough to cause a spill.

BTW, I notice that in this situation, readtup_heap seems to be
palloc'ing in the caller's context, but it counts the memory as
if it were in the tuplestore's context. Somebody's confused there.

regards, tom lane