+++ 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
reason: Process was terminated by signal 6
--- Additional comment from firstname.lastname@example.org on 2009-11-24 03:42:28 EST ---
Created an attachment (id=373362)
--- Additional comment from email@example.com 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 firstname.lastname@example.org 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 email@example.com 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.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
Created attachment 413701 [details]
Do bounds checking on framebuffer updates
Fix built in gtk-vnc-0.3.10-2.el6
Could you please retest with the latest RC?
NB, the original QEMU bug that exposed this problem is now solved, so current QEMU won't reproduce the bug. Testing with the original broken QEMU and fixed GTK-VNC shows this issue fixed.
Thank you for your report.
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.