Peter Geoghegan <pg@bowt.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