Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 590068 - GTK-VNC does not do proper bounds checking on framebuffer updates
GTK-VNC does not do proper bounds checking on framebuffer updates
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gtk-vnc (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Daniel Berrange
desktop-bugs@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-07 12:10 EDT by Daniel Berrange
Modified: 2010-11-15 08:58 EST (History)
2 users (show)

See Also:
Fixed In Version: gtk-vnc-0.3.10-2.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 540810
Environment:
Last Closed: 2010-11-15 08:58:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Do bounds checking on framebuffer updates (6.45 KB, patch)
2010-05-13 05:52 EDT, Daniel Berrange
no flags Details | Diff

  None (edit)
Description Daniel Berrange 2010-05-07 12:10:17 EDT
+++ 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@gmail.com on 2009-11-24 03:42:28 EST ---

Created an attachment (id=373362)
File: backtrace

--- Additional comment from dmalcolm@redhat.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 crobinso@redhat.com 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 berrange@redhat.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.
Comment 1 RHEL Product and Program Management 2010-05-07 12:31:41 EDT
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
inclusion.
Comment 2 Daniel Berrange 2010-05-13 05:52:57 EDT
Created attachment 413701 [details]
Do bounds checking on framebuffer updates
Comment 3 Daniel Berrange 2010-05-13 11:06:48 EDT
Fix built in gtk-vnc-0.3.10-2.el6
Comment 5 Radek Lat 2010-10-11 05:38:55 EDT
Could you please retest with the latest RC?
http://download.devel.redhat.com/rel-eng/RHEL6.0-RC-4/
Comment 6 Daniel Berrange 2010-10-13 10:53:17 EDT
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.
Comment 7 Radek Lat 2010-10-13 10:58:32 EDT
Thank you for your report.
Comment 8 releng-rhel@redhat.com 2010-11-15 08:58:38 EST
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.

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