From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Kurt Roeckx <kurt(at)roeckx(dot)be> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Gcc 4.4 causes abort in plpython. |
Date: | 2008-12-29 12:25:47 |
Message-ID: | 20081229122547.GC4545@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2008-12-29 12:40:56 | Re: dblink vs SQL/MED |
Previous Message | Peter Eisentraut | 2008-12-29 12:20:34 | Re: incoherent view of serializable transactions |