Bug 85110
| Summary: | vncviewer quits with "Rect too large" | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Pete Zaitcev <zaitcev> |
| Component: | vnc | Assignee: | Tim Waugh <twaugh> |
| Status: | CLOSED WORKSFORME | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 9 | CC: | mgahagan |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-09-16 22:14:23 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: | |||
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. |
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" localhost:0 VNC server supports protocol version 3.3 (viewer 3.3) Password: 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): vnc-3.3.3r2-43 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.