+++ 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 dmalcolm on 2009-11-30 22:13:53 EST ---

*** Bug 540016 has been marked as a duplicate of this bug. ***

--- Additional comment from dmalcolm on 2009-11-30 22:14:44 EST ---

*** Bug 539957 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2009-12-01 14:45:18 EST ---

*** Bug 541574 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2009-12-01 14:46:04 EST ---

*** Bug 541839 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2009-12-01 14:46:18 EST ---

*** Bug 543103 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2009-12-01 14:47:28 EST ---

*** Bug 542910 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2009-12-01 14:47:36 EST ---

*** Bug 542666 has been marked as a duplicate of this bug. ***

--- Additional comment from berrange on 2009-12-01 15:06:45 EST ---

Unfortunately the stack traces are all totally useless, because X errors are always received asynchronously. The real cause of the error will have been some X API call some time earlier, not the one shown in the stack trace.

Normally you have to run a GTK app with the  --sync command line flag to force the errors to be reported synchronously, but virt-manager isn't alowing this flag through to GTK.

Does anyone have any information about what they were doing, or what happened just as this problem occurred ?  For example was anyone using the VNC console, and was the guest perhaps booting & changing display resolution at the time this happened ?

--- Additional comment from redhat on 2009-12-01 16:52:38 EST ---

I am running gnome desktop (default), on a laptop that has been upgraded from fc11 to fc12 using 'yum upgrade'.

I run virt-manager from the Applications->System Tools menu.

I don't use the vnc console interface. I have CDROM attached and I got to manage to reproduce the crash about 2 out of 10 tries.

starting virt-manager from console crashed once on me just yet. I COULD report it, but it will most likely be a duplicate again.. It appeared only to happen when I had the graphical console tab active, though it's not consistent.

I'm running on a HP laptop with ATI graphics, for what that matters. if any more information is needed, I'd be happy to assist.

--- Additional comment from sniffit on 2009-12-01 19:49:01 EST ---

I was unable to reproduce this error as for now. Basically what happened was that I was running Virt-Manager and cycling (alt+tabbing) between that and the terminal that was running revisor-cli. 

Virt-Manager was running a single instance of Fedora 12 that I respun earlier and was attempting to reposync with the updates repository. Both manager and VNC were open during the time the crash happened.

Immediately after submitting this bug report, I relaunched via Application > System Tools > Virtual Machine Manager and found the virtual machine still running. After several tries to replicate the crash, I gave up due to the time of the day.

I wish I could be more specific as to how this happened. Will try to replicate the crash when possible. 

Currently running 2.6.31.6-145.fc12.x86_64 with 8GB of RAM, 512MB dedicated to the virtual machine that was running when the crash happened.

--- Additional comment from berrange on 2009-12-02 05:44:36 EST ---

Robert: if you have the graphic console tab active, then that is what I mean by using VNC :-)

My thinking is that this could be somehow related to this bug

  https://bugzilla.redhat.com/show_bug.cgi?id=538856

In both these cases it is conceivable that the QEMU VNC server is sending back some bogus framebuffer update to virt-manager, making it draw out-side the framebuffer boundaries, or requesting a stupidly large framebuffer which could result in the X 'Value out of range' error we're seeing in this bug.


If anyone here who can reproduce this actively uses the VNC graphical console for guests, and is willing to try out the standalone virt-viewer for their guest that may help. eg  

   virt-viewer --gtk-vnc-debug  -c qemu:///system  NAME-OF-GUEST  1>vnc.log  2>&1

will popup a graphical console for the guest and print debug info to stdout. If virt-viewer also experiances crashes then that would confirm the problem as being in the VNC client/server, rather than virt-manager itself.

--- Additional comment from berrange on 2009-12-02 05:45:39 EST ---

Cole: we should also try and get virt-manager to honour GTK command line arguments, because it would be useful in this scenario to be able to ask people to run virt-manager using  the '--sync' arg for GTK, and the '--gtk-vnc-debug' arg for GTK-VNC.

--- Additional comment from crobinso on 2009-12-02 11:56:53 EST ---

(In reply to comment #14)
> Cole: we should also try and get virt-manager to honour GTK command line
> arguments, because it would be useful in this scenario to be able to ask people
> to run virt-manager using  the '--sync' arg for GTK, and the '--gtk-vnc-debug'
> arg for GTK-VNC.  

Just spent a while looking at this, and I don't think pygtk supports it. We either need gtk.init_with_args or gtk_get_option_group exposed via the bindings, which AFAICT they aren't :(

--- Additional comment from dmalcolm on 2009-12-02 12:35:45 EST ---

> Just spent a while looking at this, and I don't think pygtk supports it. We
> either need gtk.init_with_args or gtk_get_option_group exposed via the
> bindings, which AFAICT they aren't :(

Cole: sounds like you should file a separate RFE against pygtk2

--- Additional comment from dmalcolm on 2009-12-03 14:18:35 EST ---

*** Bug 543856 has been marked as a duplicate of this bug. ***

--- Additional comment from dmalcolm on 2009-12-03 14:58:05 EST ---

*** Bug 544055 has been marked as a duplicate of this bug. ***

--- Additional comment from michael.hagmann on 2009-12-03 15:05:26 EST ---

Hi 

Just installed a fresh F12 x86_64 with kvm on my laptop and ontop 2 virt Maschines. try to changes something in the configtab and gone. nothing special.

Michael

--- Additional comment from dmalcolm on 2009-12-11 15:50:13 EST ---

*** Bug 546681 has been marked as a duplicate of this bug. ***

--- Additional comment from dmalcolm on 2009-12-14 11:52:53 EST ---

*** Bug 547365 has been marked as a duplicate of this bug. ***

--- Additional comment from dmalcolm on 2009-12-14 12:04:19 EST ---

(In reply to comment #15)
> (In reply to comment #14)
> > Cole: we should also try and get virt-manager to honour GTK command line
> > arguments, because it would be useful in this scenario to be able to ask people
> > to run virt-manager using  the '--sync' arg for GTK, and the '--gtk-vnc-debug'
> > arg for GTK-VNC.  
> 
> Just spent a while looking at this, and I don't think pygtk supports it. We
> either need gtk.init_with_args or gtk_get_option_group exposed via the
> bindings, which AFAICT they aren't :(  

I spent some time looking at how pygtk parses command-line options for bug 543278; as far as I can see, pygtk2-2.16.0-1.fc12.i686 initializes libgtk by calling
  /usr/lib/python2.6/site-packages/gtk-2.0/gtk/__init__.py:_init()
on import of gtk, which calls: 
  _gtk.init_check()
which is defined in /usr/src/debug/pygtk-2.16.0/gtk/gtk.override (and thus the generated file: /usr/src/debug/pygtk-2.16.0/gtk/gtk.c):
   _wrap_gtk_init_check(PyGObject *self, PyObject *args)
which scrapes the argv values from Python's "argv" PyListObject (of PyStringObject), and converts it to a GLib char**, calling gtk_init_check upon it.

I ran: gdb --args python /usr/bin/istanbul --sync
then:
(gdb) break _wrap_gtk_init_check
and was able to verify that pygtk does indeed pass "--sync" to the library initialization, and the relevant internal boolean got set (_gdk_synchronize)

However, I don't know how to wire up the --gtk-vnc-debug processing for _this_ bug.

--- Additional comment from dmalcolm on 2009-12-18 13:42:56 EST ---

We tracked down the XError issue in istanbul (see bug 543278); it turned out to be the switch to client-side windows in gtk-2.18.

From
http://library.gnome.org/devel/gtk/stable/gtk-migrating-ClientSideWindows.html
"A small gotcha is that the GDK_WINDOW_XID() call is no longer a trivial
accessor for the XID of the window, and thus must not be called from another
thread without taking locking precautions."

I wonder if something similar is happening in this bug?

Is virt-manager multithreaded?  (If so, if anyone manages to trap this in gdb, try runnning "t a a bt" and see if other threads are calling into the X server)

--- Additional comment from crobinso on 2009-12-18 15:34:24 EST ---

Yes, virt-manager is multithreaded. So the problem could be multiple threads doing X/gtk stuff without proper locking? It's reasonable there are issues like that in virt-manager.

--- Additional comment from dmalcolm on 2009-12-21 15:23:06 EST ---

*** Bug 549135 has been marked as a duplicate of this bug. ***

--- Additional comment from dmalcolm on 2009-12-22 15:03:36 EST ---

*** Bug 549631 has been marked as a duplicate of this bug. ***

--- Additional comment from dmalcolm on 2010-01-04 14:07:51 EST ---

*** Bug 551629 has been marked as a duplicate of this bug. ***

--- Additional comment from dmalcolm on 2010-01-07 20:04:23 EST ---

*** Bug 552776 has been marked as a duplicate of this bug. ***

--- Additional comment from dmalcolm on 2010-01-07 20:08:54 EST ---

*** Bug 552993 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-01-26 11:48:09 EST ---

*** Bug 549987 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-01-26 11:48:37 EST ---

*** Bug 557281 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-01-26 11:49:13 EST ---

*** Bug 556945 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-01-26 11:49:34 EST ---

*** Bug 556933 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-01-26 11:50:22 EST ---

*** Bug 556876 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-01-26 11:50:49 EST ---

*** Bug 556875 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-01-26 11:51:10 EST ---

*** Bug 556609 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-01-26 11:51:33 EST ---

*** Bug 555626 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-01-26 11:52:49 EST ---

*** Bug 554028 has been marked as a duplicate of this bug. ***

--- Additional comment from dskieweg on 2010-02-23 10:48:27 EST ---

I started getting this error after a YUM update (delayed) on 2/22/2010

Result of virt-viewer --gtk-vnc-debug  -c qemu:///system  XPSP2  1>vnc.log2>&1 :

virt-viewer:26243): gtk-vnc-DEBUG: Started background coroutine
(virt-viewer:26243): gtk-vnc-DEBUG: Resolving host localhost 5900
(virt-viewer:26243): gtk-vnc-DEBUG: Trying socket 7
(virt-viewer:26243): gtk-vnc-DEBUG: Protocol initialization
(virt-viewer:26243): gtk-vnc-DEBUG: Server version: 3.8
(virt-viewer:26243): gtk-vnc-DEBUG: Using version: 3.8
(virt-viewer:26243): gtk-vnc-DEBUG: Possible auth 1
(virt-viewer:26243): gtk-vnc-DEBUG: Thinking about auth type 1
(virt-viewer:26243): gtk-vnc-DEBUG: Decided on auth type 1
(virt-viewer:26243): gtk-vnc-DEBUG: Waiting for auth type
(virt-viewer:26243): gtk-vnc-DEBUG: Choose auth 1
(virt-viewer:26243): gtk-vnc-DEBUG: Checking auth result
(virt-viewer:26243): gtk-vnc-DEBUG: Success
(virt-viewer:26243): gtk-vnc-DEBUG: Pixel format BPP: 32,  Depth: 24, Byte order: 1234, True color: 1
             Mask  red: 255, green: 255, blue: 255
             Shift red:  16, green:   8, blue:   0
(virt-viewer:26243): gtk-vnc-DEBUG: Display name 'QEMU (XPSP2)'
(virt-viewer:26243): gtk-vnc-DEBUG: Setting depth color to 24 (32 bpp)
(virt-viewer:26243): gtk-vnc-DEBUG: Visual mask: 16711680 65280 255
      shift:  16   8   0
(virt-viewer:26243): gtk-vnc-DEBUG: Mask local: 255 255 255
    remote: 255 255 255
    merged: 255 255 255
(virt-viewer:26243): gtk-vnc-DEBUG: Pixel shifts
   right:  16   8   0
    left:  16   8   0
(virt-viewer:26243): gtk-vnc-DEBUG: Running main loop
(virt-viewer:26243): gtk-vnc-DEBUG: Expose 0x0 @ 1024,768

--- Additional comment from crobinso on 2010-02-26 20:54:28 EST ---

*** Bug 560400 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-02-26 20:56:41 EST ---

*** Bug 561207 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-02-26 20:57:05 EST ---

*** Bug 561496 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-02-26 20:58:53 EST ---

*** Bug 568183 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-02-26 20:59:14 EST ---

*** Bug 568891 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-02-26 21:01:16 EST ---

Okay, I've fixed upstream virt-manager to abide the --sync option: the reason it didn't work is because we were importing gtk _after_ parsing command line options, so --sync wasn't stripped, and optparse barfed. I'll backport the cset shortly.

--- Additional comment from jmminaz on 2010-03-11 21:24:03 EST ---



Comment
-----
Try to reinstall freebsd 8.0-RELEASE

--- Additional comment from jmorris on 2010-03-11 23:05:38 EST ---



How to reproduce
-----
1. Installed F13 Alpha
2. tried to boot after the installer completed and shut down

The VM did actually boot, upon restarting virt-manager I reconnected to the VM as it was still booting up.

--- Additional comment from dallan on 2010-03-16 21:34:38 EDT ---



How to reproduce
-----
Hi Cole, unclear how to reproduce--the crash happened with an open console when I hit the 'Play' button to start the VM.  I tried to reproduce it, but no crash...hope the backtrace helps, if not, just close it.

--- Additional comment from david.m.beer on 2010-03-22 08:30:04 EDT ---



How to reproduce
-----
1. Opened virt-manager
2. Selected WinXP VM
3. Selected the open vm option, modified the vm added a usb device
4. Then Click the start button


Comment
-----
Added a usb device to the machine then clicked start button

--- Additional comment from crobinso on 2010-03-22 15:39:11 EDT ---

virt-manager-0.8.2-3.fc12 should be heading towards updates-testing. This package now abides the --sync option, which will help track down this error. If you are regularly seeing crash, update virt-manager to the latest version in updates-testing and try one of the following:

Put alias virt-manager="virt-manager --sync" in your .bashrc, or
Add --sync to /usr/bin/virt-manager options (will add sync even from the desktop menus)

If you reproduce with --sync, please post the output here.

FYI, it sounds like people are hitting this error mostly when starting a VM, which means it is probably related to VNC.

--- Additional comment from gaetan on 2010-03-23 12:31:50 EDT ---

# yum update --enablerepo=updates-testing virt-manager
Modules complémentaires chargés : presto, refresh-packagekit
Configuration du processus de mise à jour
Aucun paquet marqué pour mise à jour

where is virt-manager-0.8.2-3.fc12 ???

--- Additional comment from gaetan on 2010-03-23 13:28:05 EDT ---



Comment
-----
crach whe, i open the vnc

--- Additional comment from crobinso on 2010-03-23 14:22:00 EDT ---

The package might take a few days to hit updates-testing.

--- Additional comment from dskieweg on 2010-03-25 11:15:45 EDT ---

(In reply to comment #53)
> The package might take a few days to hit updates-testing.   
 
rpm -qa|grep virt-manager
virt-manager-0.8.2-3.fc12.noarch

virt-manager --sync
virt-viewer --gtk-vnc-debug  -c qemu:///system  XPSP2  1>vnc.log4>&1

(virt-viewer:6800): gtk-vnc-DEBUG: Started background coroutine
(virt-viewer:6800): gtk-vnc-DEBUG: Resolving host localhost 5900
(virt-viewer:6800): gtk-vnc-DEBUG: Trying socket 7
(virt-viewer:6800): gtk-vnc-DEBUG: Protocol initialization
(virt-viewer:6800): gtk-vnc-DEBUG: Server version: 3.8
(virt-viewer:6800): gtk-vnc-DEBUG: Using version: 3.8
(virt-viewer:6800): gtk-vnc-DEBUG: Possible auth 1
(virt-viewer:6800): gtk-vnc-DEBUG: Thinking about auth type 1
(virt-viewer:6800): gtk-vnc-DEBUG: Decided on auth type 1
(virt-viewer:6800): gtk-vnc-DEBUG: Waiting for auth type
(virt-viewer:6800): gtk-vnc-DEBUG: Choose auth 1
(virt-viewer:6800): gtk-vnc-DEBUG: Checking auth result
(virt-viewer:6800): gtk-vnc-DEBUG: Success
(virt-viewer:6800): gtk-vnc-DEBUG: Pixel format BPP: 32,  Depth: 24, Byte order: 1234, True color: 1
             Mask  red: 255, green: 255, blue: 255
             Shift red:  16, green:   8, blue:   0
(virt-viewer:6800): gtk-vnc-DEBUG: Display name 'QEMU (XPSP2)'
(virt-viewer:6800): gtk-vnc-DEBUG: Setting depth color to 24 (32 bpp)
(virt-viewer:6800): gtk-vnc-DEBUG: Visual mask: 16711680 65280 255
      shift:  16   8   0
(virt-viewer:6800): gtk-vnc-DEBUG: Mask local: 255 255 255
    remote: 255 255 255
    merged: 255 255 255
(virt-viewer:6800): gtk-vnc-DEBUG: Pixel shifts
   right:  16   8   0
    left:  16   8   0
(virt-viewer:6800): gtk-vnc-DEBUG: Running main loop
(virt-viewer:6800): gtk-vnc-DEBUG: Expose 0x0 @ 1024,768

--- Additional comment from bethebeast on 2010-03-28 14:03:27 EDT ---



How to reproduce
-----
1. open virt-manager
2. open a remote connection with qemu+ssh 
3. when the remote server is open, try to open a virtual machine


Comment
-----
i want to tell that this bug is not easily reproducable, because virt-manager doesn't crash every time i open a remote connection.

--- Additional comment from abo.se on 2010-03-29 06:42:24 EDT ---



How to reproduce
-----

1. virt-manager and one virtual machine view window was open. This virtual machine was shut down. (It had been shut down by Anaconda after a successful F13 installation.)
2. I clicked the button to start the virtual machine.
3. Possibly I switched desktops.

--- Additional comment from dbn.lists on 2010-03-30 10:47:46 EDT ---



How to reproduce
-----
1. Try to open a VM by double-click.
2. Crash.


Comment
-----
Unfortunately, this wasn't reproducable, but I opened up virt-manager, authenticated with polkit, then tried to open my one VM by double clicking. The only thing different than usual is that the last time I opened it was with a different user on the system that had never run the VM before. I don't think that would matter, but maybe.

--- Additional comment from jon.fairbairn.ac.uk on 2010-04-04 15:03:01 EDT ---



Comment
-----
Deleted default NIC from VM, added one to a different virtual net and booted the vm

--- Additional comment from crobinso on 2010-04-05 12:09:53 EDT ---

*** Bug 573395 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-04-05 12:10:06 EDT ---

*** Bug 574308 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-04-05 12:10:12 EDT ---

*** Bug 577273 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-04-05 12:13:30 EDT ---

*** Bug 568982 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-04-05 12:13:37 EDT ---

*** Bug 570322 has been marked as a duplicate of this bug. ***

--- Additional comment from fish+redhatbugzilla on 2010-04-06 21:50:14 EDT ---



How to reproduce
-----
I don't recall what I was doing when this happened.

Comment
-----
I'm sorry, I don't remember what I was doing.

--- Additional comment from rjwgnr27 on 2010-04-07 16:01:16 EDT ---



How to reproduce
-----
1. Running Windows7 in kvm virtual maching.
2. Stopped VM
3. deleted audio device (AC97)
4. added new audio device (SB16)
5. Restarted VM


Comment
-----
Needed to change virtual audio device.  Shutdown running Win7 VM, deleted old audio (AC97), added new device (SB16), and did "Virtual Machine -> Run" menu.  virt-manager then crashed.

--- Additional comment from lochner on 2010-04-09 18:18:29 EDT ---

I was experiencing this problem consistently up until a few weeks ago.  I reported the bug (it is a duplicate of this bug).  Is it possible that there has been an update released, perhaps to gtk-vnc, that corrected the problem?

--- 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 crobinso on 2010-04-13 12:56:16 EDT ---

*** Bug 580041 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-04-13 12:56:24 EDT ---

*** Bug 579719 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-04-13 12:56:33 EDT ---

*** Bug 580967 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-04-13 12:56:43 EDT ---

*** Bug 581189 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2010-04-13 12:56:47 EDT ---

*** Bug 581261 has been marked as a duplicate of this bug. ***

--- Additional comment from theophanis_kontogiannis on 2010-04-15 09:19:12 EDT ---



How to reproduce
-----
1. Open VM
2. Start WinXP virtual Machine
3. the VM crashed

--- Additional comment from bcl on 2010-04-17 00:26:07 EDT ---



Comment
-----
Unknown how to repeat. I was trying to do a cdrom install from a dvd iso. The install had previously worked fine. I shut down the virt, switched boot method to cdrom and re-started it. disk i/o spiked for about 30 seconds and then it crashed.

--- Additional comment from loganjerry on 2010-04-20 16:28:11 EDT ---



How to reproduce
-----
1. Probably not (very) reproducible, since I've done exactly the same thing dozens of times before.
2.
3.


Comment
-----
I have a CentOS 5.4 guest with a modified kernel, running on an F-12 host.  The modified kernel died (which is why I'm doing this in a VM!), so I clicked the button to force the guest to stop.  I left the guest window open, and hit the run button to restart it.  The crash occurred quickly enough after hitting the button that it appeared instant to this slow human.  I have a custom /etc/X11/xorg.conf in the guest, so the guest window is larger than the default.

--- Additional comment from ros on 2010-04-23 05:52:22 EDT ---



How to reproduce
-----
1. 
2.
3.


Comment
-----
Behaviour could not be reproduced on purpose.
Just start virt-manager and authenticate as root and start one of your virtual machines. At this point, virt-manager crashed. The virtual machine nevertheless started without errors and could be accessed directly after virt-manager was started again.
 On this machine, this crash occured for the first time.

--- 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.

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

*** Bug 563711 has been marked as a duplicate of this bug. ***

--- Additional comment from berrange on 2010-04-26 14:27:00 EDT ---

*** Bug 561038 has been marked as a duplicate of this bug. ***

--- Additional comment from berrange on 2010-04-26 14:27:06 EDT ---

*** Bug 558688 has been marked as a duplicate of this bug. ***

--- Additional comment from berrange on 2010-04-26 14:27:12 EDT ---

*** Bug 556887 has been marked as a duplicate of this bug. ***

--- Additional comment from berrange on 2010-04-26 14:27:23 EDT ---

*** Bug 538856 has been marked as a duplicate of this bug. ***