Red Hat Bugzilla – Bug 429970
python crashes with assertion
Last modified: 2008-11-13 07:08:33 EST
Description of problem:
This may be a pygobject problem. It's unclear to me.
Running a new build of conduit, and then exiting causes a python crash
The conduit build can be found here:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. run conduit
2. quit conduit
3. notice crash
python: Modules/gcmodule.c:276: visit_decref: Assertion `gc->gc.gc_refs != 0'
[Thread -1223754864 (LWP 12446) exited]
[Thread -1256592496 (LWP 12448) exited]
[Thread -1246102640 (LWP 12447) exited]
[Thread -1213265008 (LWP 12443) exited]
Program received signal SIGABRT, Aborted.
[Switching to Thread -1208518976 (LWP 12442)]
0x00110402 in __kernel_vsyscall ()
#0 0x00110402 in __kernel_vsyscall ()
#1 0x004c9690 in raise () from /lib/libc.so.6
#2 0x004caf91 in abort () from /lib/libc.so.6
#3 0x004c293e in __assert_fail () from /lib/libc.so.6
#4 0x04ccb5cd in visit_decref (op=0xa4534b4, data=0x0)
#5 0x00127731 in pygobject_traverse (self=0xa45357c,
visit=0x4ccb520 <visit_decref>, arg=0x0) at pygobject.c:1033
#6 0x04c748f4 in subtype_traverse (self=0xa45357c,
visit=0x4ccb520 <visit_decref>, arg=0x0) at Objects/typeobject.c:539
#7 0x04ccbb98 in collect (generation=2) at Modules/gcmodule.c:295
#8 0x04ccc49f in PyGC_Collect () at Modules/gcmodule.c:1265
#9 0x04cc022b in Py_Finalize () at Python/pythonrun.c:387
#10 0x04cca88f in Py_Main (argc=1, argv=0xbfe63b34) at Modules/main.c:545
#11 0x080485d2 in main (argc=Cannot access memory at address 0x309a
) at Modules/python.c:23
The only time I've seen this is with external to python .so modules.
Unable to reproduce this using the pygobject2 package from Rawhide:
Is running and quitting conduit after a fresh install sufficient or do I need to
configure conduit in some way for this crash to occur?
Yes, starting and stopping are enough to trigger it. I removed my ~/.conduit
directory and it didn't change anything.
When I tried to test by upgrading pygobject2, I get this:
[bjohnson@localhost ~]$ conduit
Traceback (most recent call last):
File "/usr/bin/conduit.real", line 21, in <module>
File "/usr/lib/python2.5/site-packages/conduit/__init__.py", line 24, in <module>
File "/usr/lib/python2.5/site-packages/gtk-2.0/gobject/__init__.py", line 30,
from gobject.constants import *
File "/usr/lib/python2.5/site-packages/gtk-2.0/gobject/constants.py", line 22,
from _gobject import type_from_name
undefined symbol: g_assertion_message_expr
Are there other packages you upgraded to test with?
This is a different bug, it's because glib2 doesn't have versioned symbols and
you need the new version of glib2.
See rhbz#428847 for another glib2 casualty
I can confirm that updating to rawhide's pygobject2 and glib2 does not fix this
Which problem ... the missing g_assertion_* symbol? Or the initial something
corrupts python's memory and then it dies?
(In reply to comment #7)
> Which problem ... the missing g_assertion_* symbol? Or the initial something
> corrupts python's memory and then it dies?
The memory corruption.
On a Rawhide system, the bug does not occur, though. Perhaps the entire Python
stack needs to be updated?
Setting to NEEDINFO until Bernard can check whether this bug is still present on
a full Rawhide/Fedora 9 system. I've not been able to reproduce it myself.
I pushed a conduit for rawhide 17 days ago, and haven't received any feedback on
it good or bad.
It is also a newer release than what I was working with before, so the bug may
have been fixed.
Following the thread at http://bugzilla.gnome.org/show_bug.cgi?id=509702#c28 it
sounds like conduit was (ab)using gnome-vfs in irregular ways.
I'm hoping the never version fixes it.
I also have a F-8 version in updates-testing that I've not received any feedback on.
Can you look at https://bugzilla.redhat.com/show_bug.cgi?id=428838#c18 (and
probably the 3 comments preceding) and see if you want to reassign this bug to
gnome vfs bindings...
It does look like a gnomevfs bug. The crash is coming from Python's garbage
collector. Need to refresh my memory on how that algorithm works.
Indeed, I can reproduce this with the sample code here:
Does gnome-vfs2 seem like the right place to bump this bug over to?
Using the same sample code I mentioned in comment #14, I can't reproduce the crash anymore on Fedora 10. Is anyone still seeing this issue?
I believe it only specifically affected F8.
Thanks. closing then with the closest resolution to OBSOLETE that we have.