abrt version: 1.1.10 architecture: x86_64 Attached file: backtrace cmdline: python /usr/share/virt-manager/virt-manager.py component: virt-manager executable: /usr/bin/python kernel: 2.6.33.6-147.2.4.fc13.x86_64 package: virt-manager-0.8.4-3.fc14 rating: 4 reason: Process /usr/bin/python was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Rawhide) time: 1280785605 uid: 500 How to reproduce ----- 1. Install the new virt-manager RPM from bug 620216 2. Start virt-manager 3. While remote controlling a guest, virt-manager crashes at random (but quite often)
Created attachment 436139 [details] File: backtrace
Thanks for filing this bug report Frame #7: /usr/share/virt-manager/virtManager/domain.py:1031, in _in_out_vector_helper(self=<vmmDomain which is: >>> vector.append(float(stats[i][n])/ceil) Frame #1: float_new(args=(<unknown at remote 0x1be4e08>,)) Frame #0: PyNumber_Float (o=<unknown at remote 0x1be4e08>) So it looks like its crashing within the float coercion of "stats[i][n]"
Assuming correct line numbers, the actual SIGSEGV is happening in: m = o->ob_type->tp_as_number; so it's happening either at the dereference of o, or of o->ob_type. (My gdb hooks emit "unknown" in safe_tp_name if either of these situations occur; perhaps they should differentiate these cases?)
Please can you install pygtk2-debuginfo and supply an updated backtrace? Thread 2: waiting on IO from virDomainGetInfo within call: frame #9: /usr/lib64/python2.7/site-packages/libvirt.py, line 765, in info (this uses PyCObject, I wonder if that's an issue?) frame #12: /usr/share/virt-manager/virtManager/domain.py, line 1212, in get_info frame #15: /usr/share/virt-manager/virtManager/domain.py, line 1920, in tick Thread 1: SIGSEGV coercing an apparently corrupt value to float (c.f. comment #2): frame #7: /usr/share/virt-manager/virtManager/domain.py:1031, in_out_vector_helper frame #10: /usr/share/virt-manager/virtManager/domain.py, line 1053, in disk_io_vector frame #13: /usr/share/virt-manager/virtManager/domain.py, line 1063, in disk_io_vector_limit frame #24 0x0000003f45673a33 in gtk_tree_view_column_cell_set_cell_data () etc; gtk main loop, though without debug info in backtrace. Looks like GTK Tree view cellrenderer for the network activity is requesting data from the app so it can render the network activity graph, but the stored data is corrupt.
libvirt-0.8.2/python/typewrappers.c makes use of PyCObject_FromVoidPtrAndDesc in 15 places. Depending on the warning level (see bug 620216), this can fail on Python 2.7 Not sure that this is the bug, though.
Created attachment 436328 [details] backtrace with glib2-debuginfo and gtk2-debuginfo installed (In reply to comment #4) > Please can you install pygtk2-debuginfo and supply an updated backtrace? pygtk2-debuginfo was already installed (it was used in the original bugreport). However, glib2-debuginfo and gtk2-debuginfo weren't installed yet, so I just installed them and regenerated the backtrace. I think that this bug is triggered every time the guest switches the display resolution
Can you still reproduce? There was a gtk-vnc update pushed that fixed a VNC crasher, maybe it solved this one as well.
The problem indeed seems to be solved already by the gtk-vnc update
Thanks, closing.