Bug 429970 - python crashes with assertion
Summary: python crashes with assertion
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-python2
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 428838
TreeView+ depends on / blocked
Reported: 2008-01-24 01:15 UTC by Bernard Johnson
Modified: 2008-11-13 12:08 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-11-13 12:08:33 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 509702 0 None None None Never

Description Bernard Johnson 2008-01-24 01:15:51 UTC
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 13:06:22 UTC
 The only time I've seen this is with external to python .so modules.

Comment 2 Matthew Barnes 2008-01-24 15:18:25 UTC
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-25 01:16:11 UTC
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-25 01:30:54 UTC
 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-25 01:32:50 UTC
 See rhbz#428847 for another glib2 casualty

Comment 6 Bernard Johnson 2008-01-27 21:02:31 UTC
I can confirm that updating to rawhide's pygobject2 and glib2 does not fix this

Comment 7 James Antill 2008-01-27 22:26:30 UTC
 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 23:23:53 UTC
(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-02-01 01:04:42 UTC
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-12 03:07:25 UTC
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 04:14:39 UTC
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 14:13:44 UTC

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 14:57:14 UTC
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 15:08:45 UTC
Indeed, I can reproduce this with the sample code here:

Comment 15 Bernard Johnson 2008-05-19 01:07:41 UTC
Does gnome-vfs2 seem like the right place to bump this bug over to?

Comment 16 Matthew Barnes 2008-11-10 20:20:34 UTC
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-13 03:41:21 UTC
I believe it only specifically affected F8.

Comment 18 Matthew Barnes 2008-11-13 12:08:33 UTC
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.