Just happened to me twice, using vncviewer tunneled through ssh (the -via argument).

Steps to Reproduce:
1. Start vncviewer and connect to server
2. Hit F8, select Options
3. Uncheck the Auto select checkbox, select 64 colours. Tight encoding is active.
4. The key to crash is to press the OK button when redraw is in progress.

If you wait until the screen is redrawed, it won't crash. I have very slow connection and complex screen, redrawing with full colour depth takes me up to ten seconds. So within this interval I'm able to reconfigure settings and will get crash once the redraw is finished.


tigervnc-1.0.0-1.fc12.x86_64
Rawhide (F12 beta)


TigerVNC Viewer for X version 1.0.0 - built Aug 28 2009 07:36:22
Copyright (C) 2002-2005 RealVNC Ltd.
Copyright (C) 2000-2006 TightVNC Group
Copyright (C) 2004-2009 Peter Astrand for Cendio AB
See http://www.tigervnc.org for information on TigerVNC.

Tue Oct 27 14:06:05 2009
 CConn:       connected to host localhost port 5599
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8

Tue Oct 27 14:06:07 2009
 TXImage:     Using default colormap and visual, TrueColor, depth 24.
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       Using Tight encoding

Tue Oct 27 14:06:12 2009
 CConn:       Using pixel format depth 6 (8bpp) rgb222
vncviewer: ../rfb/zrleDecode.h:196: void rfb::zrleDecode8(const rfb::Rect&, rdr::InStream*, rdr::ZlibInStream*, rdr::U8*, rfb::CMsgHandler*): Assertion `len <= end - ptr' failed.
Aborted



#0  0x00007ffff675b575 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff675cd55 in abort () at abort.c:92
#2  0x00007ffff6754655 in __assert_fail (assertion=0x46a393 "len <= end - ptr", file=<value optimized out>, line=196, 
    function=0x46a5e0 "void rfb::zrleDecode8(const rfb::Rect&, rdr::InStream*, rdr::ZlibInStream*, rdr::U8*, rfb::CMsgHandler*)")
    at assert.c:81
#3  0x000000000043dd98 in rfb::zrleDecode8 (r=<value optimized out>, is=<value optimized out>, zis=0x6cd400, buf=<value optimized out>, 
    handler=<value optimized out>) at ../rfb/zrleDecode.h:196
#4  0x000000000045062c in rfb::CMsgReader::readRect (this=0x6ce650, r=..., encoding=16) at CMsgReader.cxx:115
#5  0x000000000041dec2 in rfb::CMsgReaderV3::readMsg (this=0x6ce650) at CMsgReaderV3.cxx:94
#6  0x000000000041609b in main (argc=<value optimized out>, argv=0x7fffffffe198) at vncviewer.cxx:400

Forgot to add, the server is running on Debian vnc4server-4.1.1+X4.3.0-31 (i.e. RealVNC).

*** Bug 541373 has been marked as a duplicate of this bug. ***

*** Bug 547370 has been marked as a duplicate of this bug. ***

How to reproduce
-----
1.Connect to a remote VNC desktop over a slow connection
2.As the page is being redrawn slowly (due to the default 24bpp), open the F8 menu and decrease the colors to 256 or 64
3.get a crash


Comment
-----
The following is the terminal output:
[brejc8@kitt ~]$ vncviewer grovel.cs.man.ac.uk:20

TigerVNC Viewer for X version 1.0.0 - built Oct 26 2009 10:57:15
Copyright (C) 2002-2005 RealVNC Ltd.
Copyright (C) 2000-2006 TightVNC Group
Copyright (C) 2004-2009 Peter Astrand for Cendio AB
See http://www.tigervnc.org for information on TigerVNC.

Wed Apr  7 19:39:37 2010
 CConn:       connected to host grovel.cs.man.ac.uk port 5920
 CConnection: Server supports RFB protocol version 3.7
 CConnection: Using RFB protocol version 3.7

Wed Apr  7 19:39:40 2010
 TXImage:     Using default colormap and visual, TrueColor, depth 24.
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       Using Tight encoding

Wed Apr  7 19:39:43 2010
 CConn:       Throughput 3218 kbit/s - changing to quality 6 
 CConn:       Using Tight encoding

Wed Apr  7 19:39:48 2010
 CConn:       Using pixel format depth 6 (8bpp) rgb222
vncviewer: ../rfb/zrleDecode.h:196: void rfb::zrleDecode8(const rfb::Rect&, rdr::InStream*, rdr::ZlibInStream*, rdr::U8*, rfb::CMsgHandler*): Assertion `len <= end - ptr' failed.
Aborted (core dumped)

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I can't reproduce this from updated F12 to updated F12.

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Seems fixed in F-13 with tigervnc-1.0.90-0.12.20100420svn4030.fc13.x86_64

Bug is still present in Fedora 14.  I can reproduce it by connecting to a OS X 10.5 machine (with vnc screen sharing enabled) over a slow connection.  It starts out trying 24-bit mode, then drops to 8-bit before the screen has even drawn, and core dumps.