Created attachment 435880 [details]
File: backtrace

My guess this is related to the python rebase. Reassigning to python

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.

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.

*** Bug 620491 has been marked as a duplicate of this bug. ***

Created attachment 436072 [details]
backtrace with pygtk2-debuginfo installed

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.

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

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.

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.

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()

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

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

Thanks for the quick fix. I just tried it and virt-manager seems to work fine again!

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

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.

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.

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.

Thanks, will test.



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