Hi Glenn, Unfortunately I've not been able to reproduce your problem, so it's hard to track down based just on the information you give here. The assertion failure means that after decompression the ZRLE data appears to be corrupted (it's being told that the length of a run is bigger than the entire rectangle). I'd be interested to know if you are using the standard linux binary release from our website or if you have built it yourself from source (what is the build time when you do "vncviewer -h"?). If you built it from source, did you use the installed zlib on your system or the statically-linked version from the distribution (it's possible there's a bug in earlier versions of zlib causing this).
I also notice a few odd things about the output of vncviewer. I presume it's being run on the Alpha since it says the native pixel format is big-endian (most significant byte first) - is this right?. Can you get some output from the linux version failing too? Also you say it says "changing to 8bit" but the auto selection never does this - do you mean "changing from 8bit"? It's also slightly odd that it says it's changing to hextile, but then failing in the ZRLE decoding - it shouldn't be getting any ZRLE updates once it's switched to hextile.... Cheers Tristan ----- Original Message ----- From: "Schmottlach, Glenn E." <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 27, 2002 8:43 PM Subject: VNC 3.3.4 Viewer Assertion Failure (zrleDecode.h) > I have installed the VNC 3.3.4 viewer/server on a number of Compaq Alpha > (TruUnix 64 Ver. 5.1.A) workstations as well as several dual-processor X86 > Linux workstations running SuSE and Redhat 7.2. The server runs fine on all > platforms but I have been encountering difficulties running the viewer on > the Linux platforms. Fairly consistently the following assertion fires: > > Assertion failed: len <= end - ptr, file ../rfb/zrleDecode.h, line 190 > > It appears this assertion is in the new ZRLE compression code. It appears > immediately after the remote screen is painted for the first time. Below is > a more detailed listing of what's going on with the viewer as it connects to > the VNC server: > > Connecting to the server with: > > > vncviewer neptune:1 > > < Enter the password for the server...> > > < The following prints out on the client side> > > Connected to VNC server, using protocol version 3.3 > VNC server default 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 default colormap and visual, TrueColor, depth 24. > Got 256 exact BGR2333 colours out of 256 > Using BGR233 pixel format: > 8 bits per pixel. > True colour: max red 7 green 7 blue 3, shift red 0 green 3 blue 6 > Throughput 20181 kbit/s - changing to Hextile > Throughput 20181 kbit/s - changing to 8bit > Using viewer's native pixel format: > 32 bits per pixel. > Most significant byte first in each pixel. > True colour: max red 255 green 255 blue 255, shift red 0 green 8 blue 16 > Assertion failed: len <= end - ptr, file ../rfb/zrleDecode.h, line 190 > Abort > > When I start the server in 8-bit mode with: > > > vncviewer -8bit neptune:1 > > The vncviewer does NOT crash (e.g. the assertion does NOT fire). Once the > session is up I can hit F8 and select the option to auto-tune the > connection. There seems to be a problem using the ZRLE code on start up. It > doesn't appear to happen as often with the Compaq Alpha workstations but I > can't say it never has. Every now and then the viewer will work correctly on > the Linux boxes - albeit rarely. Has anyone seen this behavior and can > suggest a fix? Any suggestions/help would be appreciated. > > Thanks, > > Glenn Schmottlach > [EMAIL PROTECTED] _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list
