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