Red Hat Bugzilla – Bug 277831
virt-manager segfault while starting "connect process"
Last modified: 2007-11-30 17:12:14 EST
Description of problem:
Not sure if this could be a dup of 277471. Since I updated to virt-manager 0.5,
if I start up a virtual machine, then try to open its console, virt-manager
exits suddenly. Syslog indicates that "/usr/share/virt" segfaulted, whatever
that is (I don't think it's the python interpreter that's crashing!). The
following are the last few lines of my ~root/.virt-manager/virt-manager.log file:
[Tue, 04 Sep 2007 23:08:14 virt-manager 4877] DEBUG (manager:633) Clicked a VM row
[Tue, 04 Sep 2007 23:08:14 virt-manager 4877] DEBUG (console:274) Trying console
[Tue, 04 Sep 2007 23:08:14 virt-manager 4877] DEBUG (console:284) Graphics
console configured at vnc://<my_hostname>:5900
[Tue, 04 Sep 2007 23:08:14 virt-manager 4877] DEBUG (console:297) Starting
connect process for <my_hostname> 5900
Version-Release number of selected component (if applicable):
virt-manager-0.5.0-1.fc8 for x86_64
Steps to Reproduce:
1. Open virt-manager
2. Double click on a VM
3. Click Run (VM starts running, but no console)
4. Close the console window
5. Double click on the VM again
Also, if I try to start the VM with the console window already open, the VM
starts running but the console window still says "not available" and no messages
appear in the log file (aside from the "VM started" message). It's not until I
close this window and try to reopen it that I get a crash.
I considered that my problem could be changes to the way the config is created
in /etc/libvirt, but I have confirmed that the same error occurs with a newly
created VM (only difference was the table device anyway).
*** Bug 277841 has been marked as a duplicate of this bug. ***
Yep, pretty likely to be a dup of bug 277471.
That said it works fine for me - so it must some difference in OS setup. Can you
try and capture a core dump for me.
install the XXXX-debuginfo RPMs for:
virt-manager, libvirt, xen, python, pygtk2, gtk2, glib2 and glibc
And then set 'ulimit -c unlimited', run virt-manager and wait for it to crash.
Then obtain a stack trace from th core file using GDB:
$ gdb /usr/bin/python core.XXXX
Where core.XXXX is the corefile generated (it'll be in the current directory you
launched virt-manager from). Attach the stack trace to this bug.
Created attachment 188431 [details]
gdb stack trace
Thanks for the stack trace - it is crashing in quite possibly the worst &
hardest to debug bit of code there is :-)
I've rebuilt the GTK-VNC with some debug options enabled. Could you grab the
.1dantest RPMs from here, install them & try and crash again - you should see at
least some debug info stuffed on stdout
If you could attach the complete set of debug messages it shows on the terminal
to this BZ, along with the complete /root/.virt-manager/virt-manager.log file it
would be very helpful.
Hmmm, are you sure those RPMs give debug info for you? I may not have something
I need for that to work:
[kyle@jane ~]$ yum list gtk-vnc\*
gtk-vnc.x86_64 0.1.0-5.fc8.1dantest installed
gtk-vnc-debuginfo.x86_64 0.1.0-5.fc8.1dantest installed
gtk-vnc-devel.x86_64 0.1.0-5.fc8.1dantest installed
gtk-vnc-python.x86_64 0.1.0-5.fc8.1dantest installed
[root@jane ~]# virt-manager
Nothing new in the virt-manager.log file either.
Turned out to be a GTK-VNC bug - fixed in rawhide.
*** This bug has been marked as a duplicate of 307531 ***