Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management with SRFs)

Joe Conway <mail(at)joeconway(dot)com> writes:
> Given the change to SRF memory management, is the following still
> necessary (or possibly even incorrect)?

> /* make sure we start with a fresh slot */
> if(retval->slot != NULL)
> ExecClearTuple(retval->slot);

I don't think it was ever necessary... but there's nothing wrong with
it either.

> All but one of the SRFs I've tried don't seem to care, but I have one
> that is getting an assertion:

> 0x42029331 in kill () from /lib/i686/libc.so.6
> (gdb) bt
> #0 0x42029331 in kill () from /lib/i686/libc.so.6
> #1 0x4202911a in raise () from /lib/i686/libc.so.6
> #2 0x4202a8c2 in abort () from /lib/i686/libc.so.6
> #3 0x08179ab9 in ExceptionalCondition () at assert.c:48
> #4 0x0818416f in pfree (pointer=0x7f7f7f7f) at mcxt.c:470
> #5 0x0806bd32 in heap_freetuple (htup=0x832bb80) at heaptuple.c:736
> #6 0x080e47df in ExecClearTuple (slot=0x832b2cc) at execTuples.c:406
> #7 0x0817cf49 in per_MultiFuncCall (fcinfo=0xbfffe8e0) at funcapi.c:88
> #8 0x40017273 in dblink_get_pkey (fcinfo=0xbfffe8e0) at dblink.c:911

> Not quite sure why yet, but I'm thinking the ExecClearTuple() is no
> longer needed/desired anyway.

You'll need to fix that anyway because the next ExecStoreTuple will try
to do an ExecClearTuple. Looks like the same tuple is being freed
twice. Once you've handed a tuple to ExecStoreTuple it's not yours to
free anymore; perhaps some bit of code in dblink has that wrong?

regards, tom lane