Red Hat Bugzilla – Bug 85110
vncviewer quits with "Rect too large"
Last modified: 2007-03-27 00:01:09 EDT
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)
Version-Release number of selected component (if applicable):
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.
Application quit as quoted above.
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.
Are these both x86 architectures (client and server)?
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.
Adding to CC.
Does this problem still happen?
I think Bladecenter switched to some Java based schtick, away from VNC protocol.