Re: BUG #7516: PL/Perl crash - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #7516: PL/Perl crash
Date
Msg-id 17684.1347558484@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #7516: PL/Perl crash  (Marko Tiikkaja <pgmail@joh.to>)
Responses Re: BUG #7516: PL/Perl crash  (Marko Tiikkaja <pgmail@joh.to>)
List pgsql-bugs
Marko Tiikkaja <pgmail@joh.to> writes:
> On 9/12/12 1:50 AM, Tom Lane wrote:
>> Marko Tiikkaja <pgmail@joh.to> writes:
>>> Joel Jacobson managed to narrow it down to this test case, which crashes
>>> consistently on Ubuntu 12.04 both with and without your patch.  I,
>>> however, wasn't able to reproduce the problem on my OS X Mountain Lion.

>> Doesn't reproduce for me either ...

> Ok, I can reproduce it on my Ubuntu virtual machine.

Hm, I wonder if it's Ubuntu-specific?  What Perl version is that exactly?

> What happens is that free_plperl_function() for some reason gets called
> with the prodesc of func0003.  Later on, func0003 wants to get rid of
> his prodesc and I get a crash.  What's weird about this is that
> current_call_data->prodesc actually points to the correct prodesc (the
> one of func0005), but still somehow something different is passed to
> free_plperl_function().

The only theory that comes to mind is that current_call_data is somehow
getting aliased (free'd and realloc'd).  I don't see how that could
happen, but it occurs to me that it's kinda dumb to be palloc'ing it
in the first place.  Its lifetime is exactly that of the call, so it
would be simpler and more foolproof to make it a local variable.

I've pushed a HEAD patch to do that, and I wonder if you could check
whether it changes anything.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case)
Next
From: Marko Tiikkaja
Date:
Subject: Re: BUG #7516: PL/Perl crash