Bug 907053
| Summary: | remote-viewer.exe crashes in 16bpp | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Bryan Yount <byount> | ||||||||
| Component: | mingw-virt-viewer | Assignee: | Marc-Andre Lureau <marcandre.lureau> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||||||
| Severity: | urgent | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 3.1.2 | CC: | acathrow, cfergeau, colin.coe, dblechte, jbiddle, mketchio, mkrcmari, pvine | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | 3.2.0 | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Windows | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | mingw-virt-viewer-0.5.3-24.el6ev | Doc Type: | Bug Fix | ||||||||
| Doc Text: |
Previously, running virt-viewer on a client machine configured with 16bpp would result in the client crashing after a few minutes of use. This was caused by a GDI leak in GTK+, related to 16bpp handling. Now, the leak has been fixed and virt-viewer will no longer crash on a 16bpp client.
|
Story Points: | --- | ||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2013-06-10 20:02:26 UTC | Type: | Bug | ||||||||
| 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
Bryan Yount
2013-02-02 23:08:25 UTC
Created attachment 692137 [details]
Screenshot of the crash on WindowsXP
See GSS ticket 783648 also. Created attachment 711506 [details]
debug window fails to launch virt-viewer
After installing virt-viewer-debug, the debug console launches but fails to then launch virt-viewer. Customer typically authenticates to the machine with an AD user but has also apparently tried installing virt-viewer and the debug console as the local admin with the same results.
(In reply to comment #22) > Created attachment 711506 [details] > debug window fails to launch virt-viewer > > After installing virt-viewer-debug, the debug console launches but fails to > then launch virt-viewer. Customer typically authenticates to the machine > with an AD user but has also apparently tried installing virt-viewer and the > debug console as the local admin with the same results. Tying 'thread apply all bt' at that prompt may give more clues as to what crashed. we are still missing informations to solve this... Created attachment 731993 [details]
virt-viewer-deubg output from crash
sadly, I can't reproduce that crash (tested on XP) There doesn't seem to be any clear GDI leak in Gtk+. Apparently, that crash could be also just memory exhaustion. How much memory the client had? It would be interesting to observe task manager free memory and GDI count (menu/view/select columns -> GDI objects) We have a user that frequently experiences remote-viewer crashes. His client PC runs Win XP SP3 (32-bit). GSS case 800701 has been updated with latest logs. I can confirm that the crash is not related to memory constraints (at least for us) as the client PC has 4GB of RAM and only 1.7GB was in use at the time of the crash. CC some more clues, I managed to reproduce the crash when the client is configured in 16bits, spice-gtk leaks tons of GDI and memory in this case. Also the rendering is pretty bad with a 32bit guest Patch sent upstream 671538, we should include it next build and see if it fixes customer crash as well. We are more than happy to do 'beta' testing... (In reply to comment #39) > Patch sent upstream 671538 Adding to the "External Tracker" blackboard fixed in mingw-gtk 2.24.13-4 included in mingw-virt-viewer-0.5.3-24.el6ev Marc-Andre, the customer reported that both his client and his guest are running in 32-bit color mode. What is recommended best practice for spice guests? Should they be set to 16-bit? Would that help performance? (In reply to comment #48) > Marc-Andre, the customer reported that both his client and his guest are > running in 32-bit color mode. What is recommended best practice for spice > guests? Should they be set to 16-bit? Would that help performance? I would stick to 32bit, unless you have very strong reason to use 16bit. Especially on client side. Ok so we are still clueless about what might cause that customer crash, sigh. I suggest we open/clone a different bug for that, because that bug is now quite long and fitted for the 16bpp crash. (In reply to comment #49) > I would stick to 32bit, unless you have very strong reason to use 16bit. > Especially on client side. > > Ok so we are still clueless about what might cause that customer crash, sigh. > > I suggest we open/clone a different bug for that, because that bug is now > quite long and fitted for the 16bpp crash. Are you saying that the new build fixes the crashing only if the person is running 16-bit color depth on the guest and it won't help us here? The customer is willing to test the new build to see if it resolves the issue anyway so let's hope that it does. If the crash still occurs with the new build, I will open a new BZ and grab new virt-viewer-debug output. Thanks! (In reply to comment #50) > Are you saying that the new build fixes the crashing only if the person is > running 16-bit color depth on the guest and it won't help us here? The > customer is willing to test the new build to see if it resolves the issue > anyway so let's hope that it does. It's probably not going to help in !16bpp cases > If the crash still occurs with the new build, I will open a new BZ and grab > new virt-viewer-debug output. Thanks! thanks, I will continue investigations.. I had a look at the user's PC who gets a lot of remote-viewer crashes and found that his PC was set to 16 bit colour although the guest (VM) was set to 32 bit. I had him change from 16 to 32bit and remote-viewer seems stable now. Good news: The crashing for my customer appears to be fixed with this build! Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-0889.html |