Re: BUG #7516: PL/Perl crash

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #7516: PL/Perl crash
Дата
Msg-id 17684.1347558484@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #7516: PL/Perl crash  (Marko Tiikkaja <pgmail@joh.to>)
Ответы Re: BUG #7516: PL/Perl crash
Список 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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case)
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: BUG #7516: PL/Perl crash