Hide Forgot
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 (assertion error). The conduit build can be found here: http://koji.fedoraproject.org/koji/taskinfo?taskID=366851 Version-Release number of selected component (if applicable): python-2.5.1-15.fc8 pygobject2-2.14.0-1.fc8 How reproducible: Always Steps to Reproduce: 1. run conduit 2. quit conduit 3. notice crash Actual results: python: Modules/gcmodule.c:276: visit_decref: Assertion `gc->gc.gc_refs != 0' failed. Expected results: no crash Additional info: [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 () (gdb) bt #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) at Modules/gcmodule.c:276 #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 (gdb) q
The only time I've seen this is with external to python .so modules.
Unable to reproduce this using the pygobject2 package from Rawhide: python-2.5.1-15.fc8 pygobject2-2.14.1-1.fc9 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> import conduit File "/usr/lib/python2.5/site-packages/conduit/__init__.py", line 24, in <module> import gobject File "/usr/lib/python2.5/site-packages/gtk-2.0/gobject/__init__.py", line 30, in <module> from gobject.constants import * File "/usr/lib/python2.5/site-packages/gtk-2.0/gobject/constants.py", line 22, in <module> from _gobject import type_from_name ImportError: /usr/lib/python2.5/site-packages/gtk-2.0/gobject/_gobject.so: undefined symbol: g_assertion_message_expr [bjohnson@localhost ~]$ 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 problem.
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.
Matthew, 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: http://bugzilla.gnome.org/show_bug.cgi?id=509702#c28
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.