Re: pl/python custom exceptions for SPI - Mailing list pgsql-hackers

From Jan Urbański
Subject Re: pl/python custom exceptions for SPI
Date
Msg-id 4D6CD19A.9030802@wulczer.org
Whole thread Raw
In response to Re: pl/python custom exceptions for SPI  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 28/02/11 19:38, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On mån, 2011-02-28 at 12:08 -0500, Tom Lane wrote:
>>> I'm seeing a core dump as well as multiple inconsistencies in error
>>> message spelling in the plpython regression tests on a Fedora 13 box
>>> (python 2.6.4).  Several buildfarm critters don't look too happy either.
> 
>> Fixed.  (Well, some of it.  We'll see ...)
> 
> Core dump is still there.  It appears to be a python assertion failure.
> I installed python's debuginfo and got this backtrace:
> 
> Program terminated with signal 6, Aborted.
> #0  0x00000032a36328f5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> Missing separate debuginfos, use: debuginfo-install keyutils-libs-1.2-6.fc12.x86_64 krb5-libs-1.7.1-17.fc13.x86_64
libcom_err-1.41.10-7.fc13.x86_64libselinux-2.0.94-2.fc13.x86_64 openssl-1.0.0c-1.fc13.x86_64 zlib-1.2.3-23.fc12.x86_64
 
> (gdb) bt
> #0  0x00000032a36328f5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1  0x00000032a36340d5 in abort () at abort.c:92
> #2  0x00000032a362b8b5 in __assert_fail (assertion=0x32a5b46391 "gc->gc.gc_refs != 0", file=<value optimized out>,
line=277,function=<value optimized out>)
 
>     at assert.c:81
> #3  0x00000032a5b0853e in visit_decref (op=<module at remote 0x7f11c3666d38>, data=<value optimized out>) at
Modules/gcmodule.c:277
> #4  0x00000032a5a7cbd9 in dict_traverse (op=
>     {'info': <built-in function info>, 'notice': <built-in function notice>, 'Fatal': <type at remote 0x1bba7e0>,
'log':<built-in function log>, 'prepare': <built-in function prepare>, 'spiexceptions': <module at remote
0x7f11c3666d38>,'SPIError': <type at remote 0x1bbacc0>, 'Error': <type at remote 0x1bba300>, 'execute': <built-in
functionexecute>, '__package__': None, 'quote_ident': <built-in function quote_ident>, 'warning': <built-in function
warning>,'subtransaction': <built-in function subtransaction>, 'quote_literal': <built-in function quote_literal>,
'quote_nullable':<built-in function quote_nullable>, 'error': <built-in function error>, 'debug': <built-in function
debug>,'__name__': 'plpy', 'fatal': <built-in function fatal>, '__doc__': None}, visit=0x32a5b084c0 <visit_decref>,
arg=0x0)
>     at Objects/dictobject.c:2003
> [...]
> #24 0x00000032a5af22c4 in PyImport_ImportModuleLevel (name=0x7f11c40c2084 "string", globals=
> 
> Don't know python enough to do anything useful with this, but the
> reference to "gc_refs" sure makes it look like something is dropping the
> ball on when to do INCREF/DECREF.

That's strange, the error occurs while trying to import the "string"
module. But the error itself seems to be caused by trying to unref the
spiexceptions module (showing up here as <module at remote
0x7f11c3666d38>). Apparently adding spiexceptions as an object to the
plpy module is not done exactly right.

I'll try to reproduce it in my environment.

Cheers,
Jan


pgsql-hackers by date:

Previous
From: Nikhil Sontakke
Date:
Subject: Re: PG signal handler and non-reentrant malloc/free calls
Next
From: Robert Haas
Date:
Subject: Re: Native XML