Bug 540810
| Summary: | Fatal error in gdk_x_error running /usr/share/virt-manager/virt-manager.py | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | thanosk <thanosk> | ||||||||
| Component: | gtk-vnc | Assignee: | Daniel Berrangé <berrange> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 12 | CC: | aalam, abo, alyavdin, andy.speagle, bcl, berrange, bethebeast, borgan, bugzilla, bugzilla-redhat-3187, bugzilla_rhn, carlosgarcia83, cbuissar, cjt, claudemir.franco, claudiorodrigo, crobinso, dallan, david.m.beer, dbn.lists, dipak.dudhabhate, dmalcolm, drewskiwooskie, dskieweg, eb30750, eblake, error, fabian.kanngiesser, fedora-bugzilla, fischer.d.r, fish+redhatbugzilla, gaetan, gcarter, giosif, gnafu_the_great, gui1ty, hbrock, ivazqueznet, james.antill, jforbes, jleexa, jmminaz, jmorris, jonathansteffan, jon.fairbairn, jyundt, katzj, ktopisal, lagarcia, larieu, lochner, loganjerry, luca.botti, marco, markhuomian, mattias.ellert, mclasen, michael.hagmann, mike.mcdonough, mmilgram, mnowak, myth778, mzatko, peter.green, petersen, philippeharrand, poelstra, pycoder666, quintesse, rbinkhor, rdassen, redhat, ribbones, rjwgnr27, ros, simo, sniffit, sochotni, theophanis_kontogiannis, tommy.reynolds, virt-maint, walovaton, zaytsevstanislav | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | i686 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | abrt_hash:03b9b910b4b80e30dba92c6d823c70726066825c | ||||||||||
| 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 17:00:10 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
thanosk
2009-11-24 08:42:24 UTC
Created attachment 373362 [details]
File: backtrace
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" *** Bug 540016 has been marked as a duplicate of this bug. *** *** Bug 539957 has been marked as a duplicate of this bug. *** *** Bug 541574 has been marked as a duplicate of this bug. *** *** Bug 541839 has been marked as a duplicate of this bug. *** *** Bug 543103 has been marked as a duplicate of this bug. *** *** Bug 542910 has been marked as a duplicate of this bug. *** *** Bug 542666 has been marked as a duplicate of this bug. *** 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 ? 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. 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. 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. 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. (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 :( > 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
*** Bug 543856 has been marked as a duplicate of this bug. *** *** Bug 544055 has been marked as a duplicate of this bug. *** 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 *** Bug 546681 has been marked as a duplicate of this bug. *** *** Bug 547365 has been marked as a duplicate of this bug. *** (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. 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) 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. *** Bug 549135 has been marked as a duplicate of this bug. *** *** Bug 549631 has been marked as a duplicate of this bug. *** *** Bug 551629 has been marked as a duplicate of this bug. *** *** Bug 552776 has been marked as a duplicate of this bug. *** *** Bug 552993 has been marked as a duplicate of this bug. *** *** Bug 549987 has been marked as a duplicate of this bug. *** *** Bug 557281 has been marked as a duplicate of this bug. *** *** Bug 556945 has been marked as a duplicate of this bug. *** *** Bug 556933 has been marked as a duplicate of this bug. *** *** Bug 556876 has been marked as a duplicate of this bug. *** *** Bug 556875 has been marked as a duplicate of this bug. *** *** Bug 556609 has been marked as a duplicate of this bug. *** *** Bug 555626 has been marked as a duplicate of this bug. *** *** Bug 554028 has been marked as a duplicate of this bug. *** 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
*** Bug 560400 has been marked as a duplicate of this bug. *** *** Bug 561207 has been marked as a duplicate of this bug. *** *** Bug 561496 has been marked as a duplicate of this bug. *** *** Bug 568183 has been marked as a duplicate of this bug. *** *** Bug 568891 has been marked as a duplicate of this bug. *** 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 ----- Try to reinstall freebsd 8.0-RELEASE 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. 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. 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 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. # 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 ----- crach whe, i open the vnc The package might take a few days to hit updates-testing. (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 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. 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. 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 ----- Deleted default NIC from VM, added one to a different virtual net and booted the vm *** Bug 573395 has been marked as a duplicate of this bug. *** *** Bug 574308 has been marked as a duplicate of this bug. *** *** Bug 577273 has been marked as a duplicate of this bug. *** *** Bug 568982 has been marked as a duplicate of this bug. *** *** Bug 570322 has been marked as a duplicate of this bug. *** 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. 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. 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? 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?
*** Bug 580041 has been marked as a duplicate of this bug. *** *** Bug 579719 has been marked as a duplicate of this bug. *** *** Bug 580967 has been marked as a duplicate of this bug. *** *** Bug 581189 has been marked as a duplicate of this bug. *** *** Bug 581261 has been marked as a duplicate of this bug. *** How to reproduce ----- 1. Open VM 2. Start WinXP virtual Machine 3. the VM crashed 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. 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. 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. 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. *** Bug 563711 has been marked as a duplicate of this bug. *** *** Bug 561038 has been marked as a duplicate of this bug. *** *** Bug 558688 has been marked as a duplicate of this bug. *** *** Bug 556887 has been marked as a duplicate of this bug. *** *** Bug 538856 has been marked as a duplicate of this bug. *** Created attachment 409439 [details]
Drop VNC connection if server sends an out of bounds update
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 *** Bug 586442 has been marked as a duplicate of this bug. *** *** Bug 586449 has been marked as a duplicate of this bug. *** *** Bug 585956 has been marked as a duplicate of this bug. *** *** Bug 585505 has been marked as a duplicate of this bug. *** *** Bug 584474 has been marked as a duplicate of this bug. *** *** Bug 584340 has been marked as a duplicate of this bug. *** *** Bug 584021 has been marked as a duplicate of this bug. *** *** Bug 582451 has been marked as a duplicate of this bug. *** 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 ----- Sorry but I don't know what happened or what I did. All I remember is that virt-manager crashed, but VM (KVM) survived. *** Bug 588545 has been marked as a duplicate of this bug. *** *** Bug 587147 has been marked as a duplicate of this bug. *** *** Bug 587173 has been marked as a duplicate of this bug. *** *** Bug 587216 has been marked as a duplicate of this bug. *** *** Bug 590671 has been marked as a duplicate of this bug. *** 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. 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. 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? This is unrelated to the original problem, please file anew bug. |