On Mon, Apr 16, 2018 at 1:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
I'm going to spend some time trying to reproduce the bug tomorrow. I
suspect that we can justify bringing tuplestore in line with tuplesort
defensively, though (i.e. doing something like 90decdba3 for
tuplestore, even in the absence of strong evidence that that will
prevent this crash).
> 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.
Sounds familiar.
> 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.
I could just kick myself for not going through tuplestore (and its
version of readtup_heap) as part of the 90decdba3 work.
--
Peter Geoghegan