Bug 429970 - python crashes with assertion
python crashes with assertion
Product: Fedora
Classification: Fedora
Component: gnome-python2 (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
Depends On:
Blocks: 428838
  Show dependency treegraph
Reported: 2008-01-23 20:15 EST by Bernard Johnson
Modified: 2008-11-13 07:08 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-13 07:08:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 509702 None None None Never

  None (edit)
Description Bernard Johnson 2008-01-23 20:15:51 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
(assertion error).

The conduit build can be found here: 

Version-Release number of selected component (if applicable):

How reproducible:

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'

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
Comment 1 James Antill 2008-01-24 08:06:22 EST
 The only time I've seen this is with external to python .so modules.
Comment 2 Matthew Barnes 2008-01-24 10:18:25 EST
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?
Comment 3 Bernard Johnson 2008-01-24 20:16:11 EST
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?
Comment 4 James Antill 2008-01-24 20:30:54 EST
 This is a different bug, it's because glib2 doesn't have versioned symbols and
you need the new version of glib2.
Comment 5 James Antill 2008-01-24 20:32:50 EST
 See rhbz#428847 for another glib2 casualty
Comment 6 Bernard Johnson 2008-01-27 16:02:31 EST
I can confirm that updating to rawhide's pygobject2 and glib2 does not fix this
Comment 7 James Antill 2008-01-27 17:26:30 EST
 Which problem ... the missing g_assertion_* symbol? Or the initial something
corrupts python's memory and then it dies?
Comment 8 Bernard Johnson 2008-01-28 18:23:53 EST
(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.
Comment 9 Michel Alexandre Salim 2008-01-31 20:04:42 EST
On a Rawhide system, the bug does not occur, though. Perhaps the entire Python
stack needs to be updated?
Comment 10 Matthew Barnes 2008-03-11 23:07:25 EDT
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.
Comment 11 Bernard Johnson 2008-03-13 00:14:39 EDT
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.
Comment 12 Bernard Johnson 2008-03-28 10:13:44 EDT

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...
Comment 13 Matthew Barnes 2008-03-31 10:57:14 EDT
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.
Comment 14 Matthew Barnes 2008-03-31 11:08:45 EDT
Indeed, I can reproduce this with the sample code here:
Comment 15 Bernard Johnson 2008-05-18 21:07:41 EDT
Does gnome-vfs2 seem like the right place to bump this bug over to?
Comment 16 Matthew Barnes 2008-11-10 15:20:34 EST
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?
Comment 17 Bernard Johnson 2008-11-12 22:41:21 EST
I believe it only specifically affected F8.
Comment 18 Matthew Barnes 2008-11-13 07:08:33 EST
Thanks. closing then with the closest resolution to OBSOLETE that we have.

Note You need to log in before you can comment on or make changes to this bug.