Red Hat Bugzilla – Bug 843590
virt-manager crashes when opening 3+ vnc consoles, fails to start again
Last modified: 2012-10-30 21:11:52 EDT
Description of problem:
When using virt-manager to open vnc sessions to a remote qemu server, the program crashes after opening 3 vnc windows. After the crash occurs, the program fails to start for the user who launched the application; this behavior persists across a reboot.
[jared@morgon ~]$ ulimit -c unlimited
[jared@morgon ~]$ virt-manager --debug --no-fork
WARNING: gnome-keyring:: couldn't connect to: /home/jared/.cache/keyring-pEsJbk/pkcs11: No such file or directory
2012-07-26 11:10:53,871 (cli:71): virt-manager startup
2012-07-26 11:10:53,872 (virt-manager:292): Launched as: /usr/share/virt-manager/virt-manager.py --debug --no-fork
2012-07-26 11:10:53,872 (virt-manager:293): GTK version: (2, 24, 11)
2012-07-26 11:10:53,873 (virt-manager:294): virtManager import: <module 'virtManager' from '/usr/share/virt-manager/virtManager/__init__.pyc'>
2012-07-26 11:10:53,992 (engine:555): No inspection thread because libguestfs is too old, not available, or libvirt is not thread safe.
2012-07-26 11:10:53,994 (systray:138): Showing systray: True
2012-07-26 11:10:53,999 (engine:346): About to connect to uris ['qemu+ssh://root@godel/system', 'qemu:///system']
2012-07-26 11:10:54,052 (manager:171): Showing manager
2012-07-26 11:10:54,088 (engine:471): window counter incremented to 1
2012-07-26 11:10:54,089 (manager:171): Showing manager
2012-07-26 11:10:54,090 (connection:991): Scheduling background open thread for qemu:///system
2012-07-26 11:10:54,090 (connection:1177): Background 'open connection' thread is running
(virt-manager:2218): Gdk-ERROR **: The program 'virt-manager' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
(Details: serial 305 error_code 11 request_code 53 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/breakpoint trap (core dumped)
[jared@morgon ~]$ gdb /usr/bin/python core.2218
GNU gdb (GDB) Fedora (188.8.131.5220120-49.fc17)
Core was generated by `/usr/bin/python /usr/share/virt-manager/virt-manager.py --debug --no-fork'.
Program terminated with signal 5, Trace/breakpoint trap.
#0 0x00007ff056a3e801 in g_logv () from /lib64/libglib-2.0.so.0
Missing separate debuginfos, use: debuginfo-install python-2.7.3-6.fc17.x86_64
#0 0x00007ff056a3e801 in g_logv () from /lib64/libglib-2.0.so.0
#1 0x00007ff056a3e992 in g_log () from /lib64/libglib-2.0.so.0
#2 0x00007ff055857238 in ?? () from /lib64/libgdk-x11-2.0.so.0
#3 0x00007ff053d4b526 in _XError () from /lib64/libX11.so.6
#4 0x00007ff053d48771 in ?? () from /lib64/libX11.so.6
#5 0x00007ff053d487b5 in ?? () from /lib64/libX11.so.6
#6 0x00007ff053d493a8 in _XReply () from /lib64/libX11.so.6
#7 0x00007ff053d3f179 in XQueryPointer () from /lib64/libX11.so.6
#8 0x00007ff055865e95 in ?? () from /lib64/libgdk-x11-2.0.so.0
#9 0x00007ff05580db8d in ?? () from /lib64/libgdk-x11-2.0.so.0
#10 0x00007ff05580e6fc in gdk_display_get_window_at_pointer () from /lib64/libgdk-x11-2.0.so.0
#11 0x00007ff055ce7cf3 in gtk_tooltip_trigger_tooltip_query () from /lib64/libgtk-x11-2.0.so.0
#12 0x00007ff056a52acd in g_slist_foreach () from /lib64/libglib-2.0.so.0
#13 0x00007ff055d29b89 in ?? () from /lib64/libgtk-x11-2.0.so.0
#14 0x00007ff05580bb97 in ?? () from /lib64/libgdk-x11-2.0.so.0
#15 0x00007ff056a37695 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#16 0x00007ff056a379c8 in ?? () from /lib64/libglib-2.0.so.0
#17 0x00007ff056a37dc2 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#18 0x00007ff055bf6c57 in gtk_main () from /lib64/libgtk-x11-2.0.so.0
#19 0x00007ff0562c85a8 in ?? () from /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/_gtk.so
#20 0x00007ff068c15e46 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#21 0x00007ff068c15d61 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#22 0x00007ff068c16b2f in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#23 0x00007ff068c16c02 in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0
#24 0x00007ff068c2fbaa in ?? () from /lib64/libpython2.7.so.1.0
#25 0x00007ff068c309a2 in PyRun_FileExFlags () from /lib64/libpython2.7.so.1.0
#26 0x00007ff068c313bb in PyRun_SimpleFileExFlags () from /lib64/libpython2.7.so.1.0
#27 0x00007ff068c42892 in Py_Main () from /lib64/libpython2.7.so.1.0
#28 0x00007ff067e85735 in __libc_start_main () from /lib64/libc.so.6
#29 0x00000000004006f1 in _start ()
Version-Release number of selected component (if applicable):
I am using the system python interpreter. libvirt, virt-manager, and qemu-kvm, were all provided by the fedora Virtualization Client group. This is occurring on a Lenovo ThinkPad W520 with the following video adapter:
01:00.0 VGA compatible controller: nVidia Corporation GF106 [Quadro 2000M] (rev a1)
The crash occurs when using the proprietary nvidia module/driver _and_ nouveau (standard, fedora built kernel and x11-drv package). This is occurs on both fedora 16 and fedora 17.
SELinux is disabled.
This seems to only when using virt-manager, I can connect to each domains vnc server using virt-viewer.
Steps to Reproduce:
1. run virt-manager
2. connect to a remote qemu server
3. run 3 domains and use virt-manager to connect to their vnc consoles.
virt-manager crashes due to X11 error - BadAlloc (insufficient resources for operation). virt-manager fails to start for the user that launched the program. This behavior persists, even after a reboot, until the the window state information is cleared from gconf.
virt-manager continues to run.
Hello I'm using Arch Linux with Awesome-WM. I have the almost same error.
virt-manager crashes due to X11 error - RenderBadPicture, and fails to start after deleting ~/.gconf/apps/virt-manager/* it will work as aspectet, but as aspected also all your configs like Connections will be lost.
Thanks for the report. What version of virt-manager is everyone using?
Is it 100% reproducible?
Does it matter what guests open up or is it specific guests that trigger the issue?
Please provide the XML config of 3 guests that trigger this (sudo virsh dumpxml $vmname)
What guest OS?
Also, you probably don't need to delete any gconf bits. Just force poweroff the VMs like sudo virsh destroy $vmname and virt-manager should start fine.
No response for a couple week, closing as INSUFFICIENT_DATA. If someone can still reproduce, and using Fedora as a host, please reopen with the data requested in Comment #2