0001577: Xvnc with depth > 8 crashes when logging on to GNOME 2.8 or KDE 3.4

OpenCSW Bug Tracker

Project:

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0001577

[vncserver] regular use

major

always

2006-04-18 01:22

2009-11-18 09:37

Reporter

gnutered

View Status

public

Assigned To

maciej

Priority

normal

Resolution

fixed

Status

closed

Summary

0001577: Xvnc with depth > 8 crashes when logging on to GNOME 2.8 or KDE 3.4

Description

A segmentation fault happens under specific circumstances, using Xvnc to log in remotely into a GNOME 2.8 session on a SPARC Solaris 9 box.

Not sure if it\'s GNOME or VNC or a combination. Reporting as a bug against GNOME, and report a bug against VNC server that links to this.

On the server, i run the following command:
sudo /opt/csw/bin/Xvnc -geometry 1024x768 -depth 24 -once -query localhost

When I use a vncviewer to connect to that, I get the login screen. When I choose GNOME session and login, it presents the GNOME 2.8 splashscreen and then crashes.

If I use \"-depth 8\", it does *not* crash (\"-depth 16\" does, though). So it\'s not just GNOME. If I use XDMCP directly (not through VNC), \"-depth 24\" is fine.

If I choose CDE instead of GNOME, all depths work. So it\'s not just VNC. But it happens with both KDE and GNOME. Resultion doesn\'t seem to matter so much.

VNC and GNOME are the latest Blastwave stable release. KDE is.

I uninstalled the SUNW gnome packages and even rebooted, but problem persists

I tried a number of clients, namely Ubunt Dapper, Windows (?TightVNC?).

A core file is produced by the segfault, but I\'m far too rusty on that level of Solaris hackery to make sense of it without expert guidance.

There is a chance that this isn\'t Xvnc\' fault, but that seems unlikely.

Additional Information

Transcript from Xvnc:

$ sudo /opt/csw/bin/Xvnc -geometry 1024x768 -depth 24 -once -query localhost -nevershared bc
Password:
18/04/06 15:18:27 Xvnc version 3.3.tight1.2.8
18/04/06 15:18:27 Copyright (C) 1999 AT&T Laboratories Cambridge.
18/04/06 15:18:27 Copyright (C) 2000-2002 Constantin Kaplinsky.
18/04/06 15:18:27 All Rights Reserved.
18/04/06 15:18:27 See http://www.uk.research.att.com/vnc [^] for information on VNC
18/04/06 15:18:27 See http://www.tightvnc.com [^] for TightVNC-specific information
18/04/06 15:18:27 Desktop name \'x11\' (core-mg01l:0)
18/04/06 15:18:27 Protocol version supported 3.3
18/04/06 15:18:27 Listening for VNC connections on TCP port 5900

18/04/06 15:18:32 Got connection from client 10.30.0.50
18/04/06 15:18:32 Protocol version 3.3
18/04/06 15:18:33 Pixel format for client 10.30.0.50:
18/04/06 15:18:33 8 bpp, depth 8
18/04/06 15:18:33 true colour: max r 7 g 7 b 3, shift r 0 g 3 b 6
18/04/06 15:18:33 rfbProcessClientNormalMessage: ignoring unknown encoding 16
18/04/06 15:18:33 Using hextile encoding for client 10.30.0.50
18/04/06 15:18:33 Pixel format for client 10.30.0.50:
18/04/06 15:18:33 32 bpp, depth 24, little endian
18/04/06 15:18:33 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
Segmentation Fault (core dumped)

Transcript from vncviewer:

tony@argon:~$ vncviewer 10.30.30.30
VNC viewer version 3.3.7 - built Feb 20 2006 12:04:05
Copyright (C) 2002-2003 RealVNC Ltd.
Copyright (C) 1994-2000 AT&T Laboratories Cambridge.
See http://www.realvnc.com [^] for information on VNC.
VNC server supports protocol version 3.3 (viewer 3.3)
No authentication needed
Desktop name \"root\'s x11 desktop (core-mg01l:0)\"
Connected to VNC server, using protocol version 3.3
VNC server default format:
  32 bits per pixel.
  Most significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Warning: Cannot convert string \"-*-helvetica-bold-r-*-*-16-*-*-*-*-*-*-*\" to type FontStruct
Using default colormap and visual, TrueColor, depth 24.
Got 256 exact BGR233 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 3421 kbit/s - changing from 8bit
Using viewer\'s native pixel format:
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
ReadFromRFBServer: rdr::EndOfStream

Tags

No tags attached.

Attached Files

Relationships

Notes
(0003432) gnutered (reporter) 2006-04-18 02:43	Another box is running Solaris 10, and does not experience that problem. It\'s tracking the Blastwave unstable repository, current as at a few weeks ago. Seeing as that\'s close to when the new stable came out, I\'m hoping the package versions are close. That box is getting close to being used so I\'m hesitant to upgrade packages on it. One other potential clue: $ ldd /opt/csw/bin/Xvnc libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libm.so.1 => /usr/lib/libm.so.1 libjpeg.so.62 => /opt/csw/lib/libjpeg.so.62 libz.so.1 => /opt/csw/lib/libz.so.1 libz.so.1 (SUNW_1.1) => (version not found) libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1 It seems to want some version of libz.so.1 but can\'t find it. $ sudo find / -name libz.so\\* -print Password: /opt/csw/lib/sparcv8plus+vis/libz.so /opt/csw/lib/sparcv8plus+vis/libz.so.1 /opt/csw/lib/sparcv8plus+vis/libz.so.1.2.3 /opt/csw/lib/sparcv9/libz.so /opt/csw/lib/sparcv9/libz.so.1 /opt/csw/lib/sparcv9/libz.so.1.2.3 /opt/csw/lib/libz.so /opt/csw/lib/libz.so.1 /opt/csw/lib/libz.so.1.2.3 /usr/lib/libz.so /usr/lib/libz.so.1 /usr/lib/sparcv9/libz.so /usr/lib/sparcv9/libz.so.1 So it seems there is a /usr/lib/libz.so.1 (it\'s a valid file). But maybe the fact that it\'s looking for something to do with SUNW_1.1 is the problem? Note, the same missing library occurs on the Solaris 10 box above, but still it works. Red herring, maybe?

(0004648) gnutered (reporter) 2007-06-24 06:29	Hmmm, in the fifteen months between reporting this bug and having it assigned, I\'ve moved on from the position that was involved with this Solaris box. So I no longer have the ability to assist further in debugging this. As far as I\'m concerned, you can close the bug.

(0007006) maciej (manager) 2009-11-18 09:37	Closing the bug as it's no longer reproducible.