Bug 540810 - Fatal error in gdk_x_error running /usr/share/virt-manager/virt-manager.py
Fatal error in gdk_x_error running /usr/share/virt-manager/virt-manager.py
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gtk-vnc (Show other bugs)
12
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
abrt_hash:03b9b910b4b80e30dba92c6d823...
:
: 538856 539957 540016 541574 541839 542666 542910 543103 543856 544055 546681 547365 549135 549631 549987 551629 552776 552993 554028 555626 556609 556875 556876 556887 556933 556945 557281 558688 560400 561038 561207 561496 563711 568183 568891 568982 570322 573395 574308 577273 579719 580041 580967 581189 581261 582451 584021 584340 584474 585505 585956 586442 586449 587147 587173 587216 588545 590671 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-24 03:42 EST by thanosk
Modified: 2010-05-12 04:19 EDT (History)
83 users (show)

See Also:
Fixed In Version: gtk-vnc-0.3.10-3.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 586074 590068 (view as bug list)
Environment:
Last Closed: 2010-05-10 13:00:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (7.38 KB, text/plain)
2009-11-24 03:42 EST, thanosk
no flags Details
virt-manager --sync backtrace from gdk_x_error (1.84 KB, text/plain)
2010-04-12 20:02 EDT, Cole Robinson
no flags Details
Drop VNC connection if server sends an out of bounds update (6.45 KB, patch)
2010-04-27 07:14 EDT, Daniel Berrange
no flags Details | Diff

  None (edit)
Description thanosk 2009-11-24 03:42:24 EST
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
Comment 1 thanosk 2009-11-24 03:42:28 EST
Created attachment 373362 [details]
File: backtrace
Comment 2 Dave Malcolm 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"
Comment 3 Dave Malcolm 2009-11-30 22:13:53 EST
*** Bug 540016 has been marked as a duplicate of this bug. ***
Comment 4 Dave Malcolm 2009-11-30 22:14:44 EST
*** Bug 539957 has been marked as a duplicate of this bug. ***
Comment 5 Cole Robinson 2009-12-01 14:45:18 EST
*** Bug 541574 has been marked as a duplicate of this bug. ***
Comment 6 Cole Robinson 2009-12-01 14:46:04 EST
*** Bug 541839 has been marked as a duplicate of this bug. ***
Comment 7 Cole Robinson 2009-12-01 14:46:18 EST
*** Bug 543103 has been marked as a duplicate of this bug. ***
Comment 8 Cole Robinson 2009-12-01 14:47:28 EST
*** Bug 542910 has been marked as a duplicate of this bug. ***
Comment 9 Cole Robinson 2009-12-01 14:47:36 EST
*** Bug 542666 has been marked as a duplicate of this bug. ***
Comment 10 Daniel Berrange 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 ?
Comment 11 Robert Hoekstra 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.
Comment 12 Ahmad Zulkarnain 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.
Comment 13 Daniel Berrange 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.
Comment 14 Daniel Berrange 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.
Comment 15 Cole Robinson 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 :(
Comment 16 Dave Malcolm 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
Comment 17 Dave Malcolm 2009-12-03 14:18:35 EST
*** Bug 543856 has been marked as a duplicate of this bug. ***
Comment 18 Dave Malcolm 2009-12-03 14:58:05 EST
*** Bug 544055 has been marked as a duplicate of this bug. ***
Comment 19 Michael Hagmann 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
Comment 20 Dave Malcolm 2009-12-11 15:50:13 EST
*** Bug 546681 has been marked as a duplicate of this bug. ***
Comment 21 Dave Malcolm 2009-12-14 11:52:53 EST
*** Bug 547365 has been marked as a duplicate of this bug. ***
Comment 22 Dave Malcolm 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.
Comment 23 Dave Malcolm 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)
Comment 24 Cole Robinson 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.
Comment 25 Dave Malcolm 2009-12-21 15:23:06 EST
*** Bug 549135 has been marked as a duplicate of this bug. ***
Comment 26 Dave Malcolm 2009-12-22 15:03:36 EST
*** Bug 549631 has been marked as a duplicate of this bug. ***
Comment 27 Dave Malcolm 2010-01-04 14:07:51 EST
*** Bug 551629 has been marked as a duplicate of this bug. ***
Comment 28 Dave Malcolm 2010-01-07 20:04:23 EST
*** Bug 552776 has been marked as a duplicate of this bug. ***
Comment 29 Dave Malcolm 2010-01-07 20:08:54 EST
*** Bug 552993 has been marked as a duplicate of this bug. ***
Comment 30 Cole Robinson 2010-01-26 11:48:09 EST
*** Bug 549987 has been marked as a duplicate of this bug. ***
Comment 31 Cole Robinson 2010-01-26 11:48:37 EST
*** Bug 557281 has been marked as a duplicate of this bug. ***
Comment 32 Cole Robinson 2010-01-26 11:49:13 EST
*** Bug 556945 has been marked as a duplicate of this bug. ***
Comment 33 Cole Robinson 2010-01-26 11:49:34 EST
*** Bug 556933 has been marked as a duplicate of this bug. ***
Comment 34 Cole Robinson 2010-01-26 11:50:22 EST
*** Bug 556876 has been marked as a duplicate of this bug. ***
Comment 35 Cole Robinson 2010-01-26 11:50:49 EST
*** Bug 556875 has been marked as a duplicate of this bug. ***
Comment 36 Cole Robinson 2010-01-26 11:51:10 EST
*** Bug 556609 has been marked as a duplicate of this bug. ***
Comment 37 Cole Robinson 2010-01-26 11:51:33 EST
*** Bug 555626 has been marked as a duplicate of this bug. ***
Comment 38 Cole Robinson 2010-01-26 11:52:49 EST
*** Bug 554028 has been marked as a duplicate of this bug. ***
Comment 39 Douglas Kieweg 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
Comment 40 Cole Robinson 2010-02-26 20:54:28 EST
*** Bug 560400 has been marked as a duplicate of this bug. ***
Comment 41 Cole Robinson 2010-02-26 20:56:41 EST
*** Bug 561207 has been marked as a duplicate of this bug. ***
Comment 42 Cole Robinson 2010-02-26 20:57:05 EST
*** Bug 561496 has been marked as a duplicate of this bug. ***
Comment 43 Cole Robinson 2010-02-26 20:58:53 EST
*** Bug 568183 has been marked as a duplicate of this bug. ***
Comment 44 Cole Robinson 2010-02-26 20:59:14 EST
*** Bug 568891 has been marked as a duplicate of this bug. ***
Comment 45 Cole Robinson 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.
Comment 46 jeremy 2010-03-11 21:24:03 EST

Comment
-----
Try to reinstall freebsd 8.0-RELEASE
Comment 47 John Morris 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.
Comment 48 Dave Allan 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.
Comment 49 David 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
Comment 50 Cole Robinson 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.
Comment 51 Gaetan Cambier 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 ???
Comment 52 Gaetan Cambier 2010-03-23 13:28:05 EDT

Comment
-----
crach whe, i open the vnc
Comment 53 Cole Robinson 2010-03-23 14:22:00 EDT
The package might take a few days to hit updates-testing.
Comment 54 Douglas Kieweg 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
Comment 55 bethebeast 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.
Comment 56 Alexander Boström 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.
Comment 57 Dan Nicholson 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.
Comment 58 Jón Fairbairn 2010-04-04 15:03:01 EDT

Comment
-----
Deleted default NIC from VM, added one to a different virtual net and booted the vm
Comment 59 Cole Robinson 2010-04-05 12:09:53 EDT
*** Bug 573395 has been marked as a duplicate of this bug. ***
Comment 60 Cole Robinson 2010-04-05 12:10:06 EDT
*** Bug 574308 has been marked as a duplicate of this bug. ***
Comment 61 Cole Robinson 2010-04-05 12:10:12 EDT
*** Bug 577273 has been marked as a duplicate of this bug. ***
Comment 62 Cole Robinson 2010-04-05 12:13:30 EDT
*** Bug 568982 has been marked as a duplicate of this bug. ***
Comment 63 Cole Robinson 2010-04-05 12:13:37 EDT
*** Bug 570322 has been marked as a duplicate of this bug. ***
Comment 64 Jamey 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.
Comment 65 Rick Wagner 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.
Comment 66 Richard A Lochner 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?
Comment 67 Cole Robinson 2010-04-12 20:02:01 EDT
Created attachment 406117 [details]
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?
Comment 68 Cole Robinson 2010-04-13 12:56:16 EDT
*** Bug 580041 has been marked as a duplicate of this bug. ***
Comment 69 Cole Robinson 2010-04-13 12:56:24 EDT
*** Bug 579719 has been marked as a duplicate of this bug. ***
Comment 70 Cole Robinson 2010-04-13 12:56:33 EDT
*** Bug 580967 has been marked as a duplicate of this bug. ***
Comment 71 Cole Robinson 2010-04-13 12:56:43 EDT
*** Bug 581189 has been marked as a duplicate of this bug. ***
Comment 72 Cole Robinson 2010-04-13 12:56:47 EDT
*** Bug 581261 has been marked as a duplicate of this bug. ***
Comment 73 Theophanis Kontogiannis 2010-04-15 09:19:12 EDT

How to reproduce
-----
1. Open VM
2. Start WinXP virtual Machine
3. the VM crashed
Comment 74 Brian Lane 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.
Comment 75 Jerry James 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.
Comment 76 Ralf Oltmanns 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.
Comment 77 Daniel Berrange 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.
Comment 78 Daniel Berrange 2010-04-26 14:26:53 EDT
*** Bug 563711 has been marked as a duplicate of this bug. ***
Comment 79 Daniel Berrange 2010-04-26 14:27:00 EDT
*** Bug 561038 has been marked as a duplicate of this bug. ***
Comment 80 Daniel Berrange 2010-04-26 14:27:06 EDT
*** Bug 558688 has been marked as a duplicate of this bug. ***
Comment 81 Daniel Berrange 2010-04-26 14:27:12 EDT
*** Bug 556887 has been marked as a duplicate of this bug. ***
Comment 82 Daniel Berrange 2010-04-26 14:27:23 EDT
*** Bug 538856 has been marked as a duplicate of this bug. ***
Comment 83 Daniel Berrange 2010-04-27 07:14:16 EDT
Created attachment 409439 [details]
Drop VNC connection if server sends an out of bounds update
Comment 84 Fedora Update System 2010-04-27 08:57:19 EDT
gtk-vnc-0.3.10-3.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/gtk-vnc-0.3.10-3.fc12
Comment 85 Cole Robinson 2010-04-27 12:27:22 EDT
*** Bug 586442 has been marked as a duplicate of this bug. ***
Comment 86 Cole Robinson 2010-04-27 12:27:29 EDT
*** Bug 586449 has been marked as a duplicate of this bug. ***
Comment 87 Cole Robinson 2010-04-27 12:27:43 EDT
*** Bug 585956 has been marked as a duplicate of this bug. ***
Comment 88 Cole Robinson 2010-04-27 12:27:48 EDT
*** Bug 585505 has been marked as a duplicate of this bug. ***
Comment 89 Cole Robinson 2010-04-27 12:28:05 EDT
*** Bug 584474 has been marked as a duplicate of this bug. ***
Comment 90 Cole Robinson 2010-04-27 12:28:11 EDT
*** Bug 584340 has been marked as a duplicate of this bug. ***
Comment 91 Cole Robinson 2010-04-27 12:28:23 EDT
*** Bug 584021 has been marked as a duplicate of this bug. ***
Comment 92 Cole Robinson 2010-04-27 12:29:05 EDT
*** Bug 582451 has been marked as a duplicate of this bug. ***
Comment 93 Fedora Update System 2010-04-27 21:19:02 EDT
gtk-vnc-0.3.10-3.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gtk-vnc'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/gtk-vnc-0.3.10-3.fc12
Comment 94 Maros Zatko 2010-04-29 09:13:12 EDT

Comment
-----
Sorry but I don't know what happened or what I did. All I remember is that virt-manager crashed, but VM (KVM) survived.
Comment 95 Cole Robinson 2010-05-04 09:40:21 EDT
*** Bug 588545 has been marked as a duplicate of this bug. ***
Comment 96 Cole Robinson 2010-05-04 09:41:15 EDT
*** Bug 587147 has been marked as a duplicate of this bug. ***
Comment 97 Cole Robinson 2010-05-04 09:41:22 EDT
*** Bug 587173 has been marked as a duplicate of this bug. ***
Comment 98 Cole Robinson 2010-05-04 09:41:28 EDT
*** Bug 587216 has been marked as a duplicate of this bug. ***
Comment 99 Cole Robinson 2010-05-10 11:52:00 EDT
*** Bug 590671 has been marked as a duplicate of this bug. ***
Comment 100 Fedora Update System 2010-05-10 12:59:58 EDT
gtk-vnc-0.3.10-3.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 101 Richard A Lochner 2010-05-11 16:28:26 EDT
I am sorry to report that I am still experiencing the problem.  I have upgraded to gtk-vnc.x86_64 0.3.10-3.fc12. 

I do NOT get an error with virt-viewer, just virt-manager.

I have also tried the --sync option with no success.
Comment 102 Richard A Lochner 2010-05-11 17:03:45 EDT
When I run virt-manager as follows:

virt-manager --debug --no-dbus --no-fork --sync -c qemu+tls://vmh001.clone1.com/system 2>virt-manager.log

The window opens for a few seconds and then I get this at the end of the log.

2010-05-11 15:59:06,137 (console:562): Graphics console configured at vnc://vmh001.clone1.com:5900
2010-05-11 15:59:06,138 (console:575): Starting connect process for vmh001.clone1.com 5900
2010-05-11 15:59:06,168 (engine:414): window counter incremented to 2
2010-05-11 15:59:06,170 (console:562): Graphics console configured at vnc://vmh001.clone1.com:5900
2010-05-11 15:59:06,170 (console:575): Starting connect process for vmh001.clone1.com 5900
2010-05-11 15:59:07,066 (console:626): Got credential request <enum VNC_DISPLAY_CREDENTIAL_CLIENTNAME of type VncDisplayCredential>
2010-05-11 15:59:07,175 (console:464): VNC initialized
python: ath.c:193: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)' failed.

Perhaps this is a different problem?
Comment 103 Daniel Berrange 2010-05-12 04:19:06 EDT
This is unrelated to the original problem, please file anew bug.

Note You need to log in before you can comment on or make changes to this bug.