+++ This bug was initially created as a clone of Bug #540810 +++

abrt detected a crash.

Attached file: backtrace
cmdline: python /usr/share/virt-manager/virt-manager.py
component: python
executable: /usr/bin/python
kernel: 2.6.31.5-127.fc12.i686.PAE
package: python-2.6.2-2.fc12
rating: 4
reason: Process was terminated by signal 6

--- Additional comment from thanosk on 2009-11-24 03:42:28 EST ---

Created an attachment (id=373362)
File: backtrace

--- Additional comment from dmalcolm on 2009-11-30 22:05:57 EST ---

Thank you for reporting this bug.

How reproducable is this problem?  If you run the program from a terminal, is an error message printed?

What version of virt-manager do you have installed?

Looking at the backtrace, it looks like a fatal error happened in frame 5 of the program's single thread inside gdk_x_error.

Reassigning component from "python" to "virt-manager"


--- Additional comment from crobinso on 2010-04-12 20:02:01 EDT ---

Created an attachment (id=406117)
virt-manager --sync backtrace from gdk_x_error

Okay, I can reproduce pretty consistently on a fully updated F12 machine:

1) In Edit->Preferences, set 'Automatically open consoles' to 'For all domains'
2) Use a script that starts and stops a couple domains every few seconds, which causes the VNC windows to pop up in virt-manager.
3) Click around a bit during all this

Has triggered reliably within 2 minutes every time.

Danpb, the backtrace is in gtk-vnc code, can you make sense of it? Anything else I can do to provide more info?

--- Additional comment from berrange on 2010-04-26 14:24:59 EDT ---

I have finally reproduced this problem with virt-viewer too. There are two bugs involved.

 1. The root cause is that QEMU is forgetting to send a DESKTOPRESIZE message if the guest resizes the guest at the time the VNC connection is still in its setup phase. This is incredibly unlikely to occur, unless your VNC client happens to connect at exactly the time the guest resizes its display. Unfortunately when a guest first boots there are typically 2-3 resizes from BIOS to GRUB to guest OS. With virt-manager automagically opening connections when a guest starts the odds of hitting the QEMU flaw are non-trivial

 2. GTK-VNC is not checking the bounds of the framebuffer updates against its known framebuffer size. Thus it tries to draw a 720x400 pixel image on a 600x480 pixel window. X gets unhappy, sends back an XError and GTK gives up & aborts the whole process.

I'm going to fix GTK-VNC to check update boundaries & close the VNC connection if it gets an out of bounds update. virt-manager should auto-reopen the VNC connection and all will likely be well since its past the resize. I'm also going to take the QEMU problem upstream.