Bug 122455 - vncviewer crashes viewing another VNC 4.0 Beta server
Summary: vncviewer crashes viewing another VNC 4.0 Beta server
Alias: None
Product: Fedora
Classification: Fedora
Component: vnc   
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-05-04 18:41 UTC by Dave Habben
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-25 15:52:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Dave Habben 2004-05-04 18:41:18 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
It takes about 1 minute to crash the vncviewer when working on a
Windows  machine running VNC 4.0 Beta 3. After the viewer crashes you
can try to reconnect to the server and it allows you to authenticate,
but as soon as it trys to display the desktop again it crashes.

GDB backtrace is included.

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

How reproducible:

Steps to Reproduce:
1. I connect to our Windows 2000 Server running VNC 4.0 Beta 3
2. Open a few windows, look at some logs
3. vncview crashes unexpectedly
4. crashes instantly after connecting back up again. 

Expected Results:  Not crashing, the windows VNC Viewer works just
fine against the same server.

Additional info:

GDB Backtrace:

Tue May  4 13:40:37 2004
 CConn:       connected to host port 5900
 CConnection: Server supports RFB protocol version 3.7
 CConnection: Using RFB protocol version 3.7
Tue May  4 13:40:40 2004
 TXImage:     Using default colormap and visual, TrueColor, depth 24.
 CConn:       Using pixel format depth 8 (8bpp) colour-map
 CConn:       Using ZRLE encoding
Program received signal SIGSEGV, Segmentation fault.
0x08067d51 in TXImage::lookup (this=0x90a1088, index=-66424728,
    g=0x90a1088, b=0xfc0a7068) at TXImage.cxx:166
166       *r = colourMap[index].r;
(gdb) bt
#0  0x08067d51 in TXImage::lookup (this=0x90a1088, index=-66424728,
    r=0x90a1088, g=0x90a1088, b=0xfc0a7068) at TXImage.cxx:166
#1  0x08074476 in rfb::PixelFormat::rgbFromPixel (this=0x90a1090,
    p=4276794024, cm=0x90a10c0, rgb=0xfeeab2b0) at PixelFormat.cxx:111
#2  0x0804cefa in DesktopWindow::setCursor (this=0x90a0b00,
    hotspot=@0xfc0a7068, size=@0x90a10c0, data=0xfc0a7068, mask=0x220005f)
    at DesktopWindow.h:46
#3  0x080852cd in rfb::CMsgReader::readSetCursor (this=0x9099330,
    hotspot=@0xfc0a7068, size=@0xfeeab3a8) at CMsgReader.cxx:144
#4  0x0806bda5 in rfb::CMsgReaderV3::readMsg (this=0x9099330) at Rect.h:39
#5  0x0806a77b in rfb::CConnection::processMsg (this=0x90a1088)
    at CConnection.cxx:87
#6  0x080634bb in main (argc=1, argv=0xfeeab440) at vncviewer.cxx:314
#7  0x002aef43 in __libc_start_main () from /lib/tls/libc.so.6
#8  0x0804bfe1 in _start ()

Comment 1 Tim Waugh 2004-05-07 09:52:18 UTC
Does upgrading the Windows side to 4.0beta4 make the problem go away?
 There were several cursor-handling problems fixed since beta3.

Comment 2 Dave Habben 2004-05-07 12:56:02 UTC
The windows server is already running 4.0b4 built Sept 4th 2003, that
was my mistake in the bug report.

Comment 3 Tim Waugh 2004-05-15 09:26:59 UTC
Can you capture the traffic of a complete session, starting from the
viewer connecting, and finished after it segfaults, using tcpdump please?

Something like: tcpdump -w capture.pcap port 5901

Then attach the capture.pcap file.

Comment 4 Dave Habben 2004-10-25 15:52:14 UTC
Never got around to closing this bug, resending the message I meant to

Upgrading the server on the windows side to 4.0beta5 (and final) seems
to have resolved it. If I can reproduce it with this version I'll
reopen the bug report.

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