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 (7.4.50.20120120-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 (gdb) bt #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. How reproducible: Unknown 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. Actual results: 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. Expected results: virt-manager continues to run.
Hello I'm using Arch Linux with Awesome-WM. I have the almost same error. Actual Results: 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. Expected results: virt-manager starts
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