Bug 620216 - virt-manager crashes with assertion failure in pygtk2 startup on Python 2.7
Summary: virt-manager crashes with assertion failure in pygtk2 startup on Python 2.7
Alias: None
Product: Fedora
Classification: Fedora
Component: pygtk2
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Colin Walters
QA Contact: Fedora Extras Quality Assurance
Whiteboard: abrt_hash:d9b872091d39d371ba238fe3c03...
: 620491 (view as bug list)
Depends On:
Blocks: Python27
TreeView+ depends on / blocked
Reported: 2010-08-01 15:42 UTC by Erik van Pienbroek
Modified: 2010-08-08 04:11 UTC (History)
12 users (show)

Fixed In Version: virt-manager-0.8.4-3.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-08-03 02:14:03 UTC
Type: ---

Attachments (Terms of Use)
File: backtrace (62.13 KB, text/plain)
2010-08-01 15:42 UTC, Erik van Pienbroek
no flags Details
backtrace with pygtk2-debuginfo installed (63.61 KB, text/plain)
2010-08-02 17:07 UTC, Erik van Pienbroek
no flags Details
Patch to virt-manager (467 bytes, patch)
2010-08-02 19:07 UTC, Dave Malcolm
no flags Details | Diff

Description Erik van Pienbroek 2010-08-01 15:42:09 UTC
abrt version: 1.1.10
architecture: x86_64
Attached file: backtrace
cmdline: python /usr/share/virt-manager/virt-manager.py
component: virt-manager
crash_function: PyDict_SetItem
executable: /usr/bin/python
package: virt-manager-0.8.4-2.fc14
rating: 4
reason: Process /usr/bin/python was killed by signal 6 (SIGABRT)
release: Fedora release 14 (Rawhide)
How to reproduce: Just start 'virt-manager' on rawhide/F14 of August 1 2010
time: 1280676535
uid: 500

Installed versions:

Comment 1 Erik van Pienbroek 2010-08-01 15:42:14 UTC
Created attachment 435880 [details]
File: backtrace

Comment 2 Cole Robinson 2010-08-02 16:24:37 UTC
My guess this is related to the python rebase. Reassigning to python

Comment 3 Dave Malcolm 2010-08-02 16:43:00 UTC
Thanks for filing this bug report:

Frame #2 is a C-level assertion failure:
python: /builddir/build/BUILD/Python-2.7/Objects/dictobject.c:759: PyDict_SetItem: Controletest 'value' faalt

Looks like a GTK input method is trying to write to a dictionary (see frame #2), it's trying to set the value for key "_PyGtk_API", but it's passing in a NULL value (see frame #4: "item=0x0" at the far end of the very long line).

This is being called by 
#5  0x00007fc317b4a616 in init_gtk ()
   from /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/_gtk.so

upon "import _gtk" at the python level.

So this looks like a pygtk2 issue; reassigning component.

Comment 4 Dave Malcolm 2010-08-02 16:44:35 UTC
Can you install pygtk2-debuginfo and reproduce this please?

> Looks like a GTK input method is trying to write to a dictionary (see frame
Looking again, there's nothing to suggest that it's specifically the input method doing this.

Comment 5 Erik van Pienbroek 2010-08-02 17:04:14 UTC
*** Bug 620491 has been marked as a duplicate of this bug. ***

Comment 6 Erik van Pienbroek 2010-08-02 17:07:44 UTC
Created attachment 436072 [details]
backtrace with pygtk2-debuginfo installed

Comment 7 Dave Malcolm 2010-08-02 17:27:29 UTC
Thanks for the backtrace.

Frame 5 is the root cause:
    /* extension API */
    PyDict_SetItemString(d, "_PyGtk_API",
			 o=PyCObject_FromVoidPtr(&functions, NULL));

Looks like PyCObject_FromVoidPtr(&functions, NULL) is returning NULL.  This might be a python 2.7 change.

Comment 8 Dave Malcolm 2010-08-02 17:40:42 UTC
Python 2.7 raises a deprecation warning on usage of that API:
static int cobject_deprecation_warning(void)
    return PyErr_WarnEx(PyExc_PendingDeprecationWarning,
        "The CObject type is marked Pending Deprecation in Python 2.7.  "
        "Please use capsule objects instead.", 1);

PyObject *
PyCObject_FromVoidPtr(void *cobj, void (*destr)(void *))
    PyCObject *self;

    if (cobject_deprecation_warning()) {
        return NULL;



Comment 9 Dave Malcolm 2010-08-02 18:23:13 UTC
I tried stepping through system-config-date's startup (which works).

Python/_warnings.c:init_filters sets Python up to ignore PendingDeprecationWarning by default, and thus most pygtk apps trigger this warning but it is ignored within warn_explicit, and thus they never trigger the assertion failure.

/usr/share/virt-manager/virt-manager.py seems to be manipulating the "warnings" module.  My hunch is that this is turning off the "ignore" filter, thus leading to the warning bubbling back up and causing the assertion failure.

Comment 10 Dave Malcolm 2010-08-02 18:45:14 UTC
The "correct" fix here is probably to port pygtk2 to the capsule API.

However this requires touching the init_pygtk macro in pygtk.h, as well as gtkmodule.c (why is this a macro?), not sure at this stage how much recompilation this would imply.

As a workaround we could rework virt-manager's initialization from:
    warnings.filterwarnings('error', module='gtk')
    warnings.filterwarnings('error', module='gtk', append=True)

which seems to fix the crash.

Comment 11 Dave Malcolm 2010-08-02 19:07:51 UTC
Created attachment 436099 [details]
Patch to virt-manager

Running with this patch makes virt-manager start under Python 2.7

However, this might conflict with error-handling goals:
# DISPLAY= virt-manager 
ERROR:root:could not open display
Traceback (most recent call last):
  File "/usr/share/virt-manager/virt-manager.py", line 413, in <module>
  File "/usr/share/virt-manager/virt-manager.py", line 285, in main
    import gtk
  File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 64, in <module>
  File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 52, in _init
RuntimeError: could not open display
Traceback (most recent call last):
  File "/usr/share/virt-manager/virt-manager.py", line 420, in <module>
    _show_startup_error(str(run_e), "".join(traceback.format_exc()))
  File "/usr/share/virt-manager/virt-manager.py", line 61, in _show_startup_error
    import gtk
  File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 64, in <module>
  File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 52, in _init

Comment 12 Dave Malcolm 2010-08-02 19:31:02 UTC
Patch added to dist-git as a workaround for now
Building for F15 as: http://koji.fedoraproject.org/koji/taskinfo?taskID=2374388
Building for F14 as: http://koji.fedoraproject.org/koji/taskinfo?taskID=2374390

Comment 13 Fedora Update System 2010-08-02 19:36:55 UTC
virt-manager-0.8.4-3.fc14 has been submitted as an update for Fedora 14.

Comment 14 Erik van Pienbroek 2010-08-02 21:06:46 UTC
Thanks for the quick fix. I just tried it and virt-manager seems to work fine again!

Comment 15 Erik van Pienbroek 2010-08-02 21:55:30 UTC
After some more testing I've found out that virt-manager crashes quite frequently while remote controlling a guest. It looks python 2.7 related as well. It's filed as bug 620581

Comment 16 Fedora Update System 2010-08-03 02:13:57 UTC
virt-manager-0.8.4-3.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 Adam Williamson 2010-08-05 21:21:59 UTC
erik: virt-manager was crashing frequently on Rawhide prior to the py 2.7 rebase - ever since I updated to Rawhide on my desktop I've been dealing with virt-manager falling over every few minutes as I use it. I've filed a few of those crashes.

Comment 18 Cole Robinson 2010-08-06 15:26:12 UTC
Adam, there was a gtk-vnc crasher that seemed pretty common. If you were seeing crashes when opening/closing VMs, it was probably that. Should be fixed with the latest build.

Comment 19 Adam Williamson 2010-08-08 04:11:40 UTC
Thanks, will test.

Fedora Bugzappers volunteer triage team

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