Bug 85110 - vncviewer quits with "Rect too large"
vncviewer quits with "Rect too large"
Product: Red Hat Linux
Classification: Retired
Component: vnc (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Tim Waugh
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-02-25 15:45 EST by Pete Zaitcev
Modified: 2007-03-27 00:01 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-16 18:14:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pete Zaitcev 2003-02-25 15:45:27 EST
Description of problem:

When accessing a console of our lab BladeServer (dhcp115.perf currently),
vncviewer quickly quits with the following log:

[zaitcev@niphredil zaitcev]$ vncviewer -depth 8 -encodings "copyrect tight"
VNC server supports protocol version 3.3 (viewer 3.3)
VNC authentication succeeded
Desktop name "IBM-MM"
Connected to VNC server, using protocol version 3.3
VNC server default format:
  8 bits per pixel.
  True colour: max red 7 green 7 blue 3, shift red 0 green 3 blue 6
Using default colormap which is TrueColor.  Pixel format:
  16 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 31 green 63 blue 31, shift red 11 green 5 blue 0
Using shared memory PutImage
Rect too large: 16384x0 at (0, 16384)
ShmCleanup called
[zaitcev@niphredil zaitcev]$

Version-Release number of selected component (if applicable):


How reproducible:

Happens 100% on my box when any actual updates come.
However, it works dandy for Matt Wilson, apparently...

Steps to Reproduce:
0. Get Mozilla without Java plugin, to prevent the normal way to access
   the server. I have to run vncviewer for other reason. Possibly relevant...
1. Log into BladeServer session with Mozilla, start server redirect, then
   open the frame source with ^U, get the password.
2. Start vncviewer in other window with the command logged above,
   enter the password.
3. Stay in text mode at the blade console. Make the blade to update
   something. "cat /etc/termcap" will do.
Actual results:

Application quit as quoted above.

Expected results:

Application continues.

Additional info:

The bandwidth needed exceeds what my DSL can provide (I've got 384Kb/s).
The vncviewer pegs the bandwidth, and perhaps this trips a bug somewhere.
Try this over ppp from home. Perhaps this is why it works for Matt in office.

Another thing... It is quite possible that IBM server provides a broken
data to the client, but I would appreciate if the client worked around it
and continued. It's not like screen is update properly anyway...
If you patch vncviewer so it produces a screen artifact, it's ok.
Comment 1 Tim Waugh 2003-03-05 12:35:08 EST
Are these both x86 architectures (client and server)?
Comment 2 Pete Zaitcev 2003-03-05 12:43:15 EST
No way to know. It may be a PPC based. It runs in the console diagnostic module.
Mike Gahagan may be able to supply this information, the box is in an RDU lab.
Comment 3 Tim Waugh 2003-03-05 12:57:38 EST
Adding to CC.
Comment 4 Tim Waugh 2005-09-16 12:42:03 EDT
Does this problem still happen?
Comment 5 Pete Zaitcev 2005-09-16 18:14:23 EDT
I think Bladecenter switched to some Java based schtick, away from VNC protocol.

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