Bug 620216 - virt-manager crashes with assertion failure in pygtk2 startup on Python 2.7
virt-manager crashes with assertion failure in pygtk2 startup on Python 2.7
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: pygtk2 (Show other bugs)
rawhide
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Colin Walters
Fedora Extras Quality Assurance
abrt_hash:d9b872091d39d371ba238fe3c03...
:
: 620491 (view as bug list)
Depends On:
Blocks: Python27
  Show dependency treegraph
 
Reported: 2010-08-01 11:42 EDT by Erik van Pienbroek
Modified: 2010-08-08 00:11 EDT (History)
12 users (show)

See Also:
Fixed In Version: virt-manager-0.8.4-3.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-02 22:14:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Erik van Pienbroek 2010-08-01 11:42:09 EDT
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
kernel: 2.6.33.6-147.2.4.fc13.x86_64
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

comment
-----
Installed versions:
python-2.7-7.fc14.x86_64
pygtk2-2.17.0-7.fc15.x86_64
virt-manager-0.8.4-2.fc14.noarch
Comment 1 Erik van Pienbroek 2010-08-01 11:42:14 EDT
Created attachment 435880 [details]
File: backtrace
Comment 2 Cole Robinson 2010-08-02 12:24:37 EDT
My guess this is related to the python rebase. Reassigning to python
Comment 3 Dave Malcolm 2010-08-02 12:43:00 EDT
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 12:44:35 EDT
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 13:04:14 EDT
*** Bug 620491 has been marked as a duplicate of this bug. ***
Comment 6 Erik van Pienbroek 2010-08-02 13:07:44 EDT
Created attachment 436072 [details]
backtrace with pygtk2-debuginfo installed
Comment 7 Dave Malcolm 2010-08-02 13:27:29 EDT
Thanks for the backtrace.

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

Looks like PyCObject_FromVoidPtr(&functions, NULL) is returning NULL.  This might be a python 2.7 change.
Comment 8 Dave Malcolm 2010-08-02 13:40:42 EDT
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;
    }

    (etc)

See:
http://docs.python.org/dev/whatsnew/2.7.html#capsules
Comment 9 Dave Malcolm 2010-08-02 14:23:13 EDT
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 14:45:14 EDT
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')
to:
    warnings.filterwarnings('error', module='gtk', append=True)

which seems to fix the crash.
Comment 11 Dave Malcolm 2010-08-02 15:07:51 EDT
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>
    main()
  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>
    _init()
  File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 52, in _init
    _gtk.init_check()
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>
    _init()
  File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 52, in _init
    _gtk.init_check()
Comment 12 Dave Malcolm 2010-08-02 15:31:02 EDT
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 15:36:55 EDT
virt-manager-0.8.4-3.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/virt-manager-0.8.4-3.fc14
Comment 14 Erik van Pienbroek 2010-08-02 17:06:46 EDT
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 17:55:30 EDT
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-02 22:13:57 EDT
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 17:21:59 EDT
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 11:26:12 EDT
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 00:11:40 EDT
Thanks, will test.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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