Bug 843590

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.