Re: Gcc 4.4 causes abort in plpython.

Kurt Roeckx wrote:

> #3  0x00000000006c8033 in MemoryContextAlloc (context=0x0, size=112)
>     at mcxt.c:507
> #4  0x00000000006abe82 in CopyErrorData () at elog.c:1082
> #5  0x00002b41ea61a755 in PLy_spi_execute_plan (ob=<value optimized out>,
>     list=<value optimized out>, limit=<value optimized out>) at plpython.c:2587

It's calling CopyErrorData with CurrentMemoryContext pointing to NULL,
which is not impossible since the GCC-inlined version of
MemoryContextSwitchTo does not check that it wasn't (the other version
does -- should we fix that?).

The question is why is that memory context set to NULL.  The code looks
like this:

PLy_spi_execute_plan( ... )
{MemoryContext    oldcontext;...oldcontext = CurrentMemoryContext;PG_TRY();{    ...}PG_CATCH();{
MemoryContextSwitchTo(oldcontext);   CopyErrorData();    ...}
 


This has been like this for quite a while, which I find surprising
because I got scolded for a similar coding pattern awhile back.  I think
I found that the variable was reversed to the value it had on entering
the block by the longjmp call.  (IIRC Tom complained because his
compiler threw a "variable might be clobbered by longjmp" warning).  We
at Command Prompt also had a similar case on the then-proprietary
Replicator code.

I think a simplistic solution is to declare the variable volatile.
Would you test that and report back?

Thanks.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.