On 28/02/11 19:38, Tom Lane wrote:
> Peter Eisentraut <pete...@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_64 libselinux-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 function execute>, '__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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
