VNC Virtual Desktop Segmentation Fault

Get Help
1

Can anyone help to identify what might be causing a segmentation fault when launching a virtual desktop? We did just complete a general 6-month update, so at this point it’s unclear what may be causing this:

Setting VNC password...
Starting VNC server...
Could not start Xvnc.


TurboVNC Server (Xvnc) 64-bit v3.2 (build 20250506)
Copyright (C) 1999-2025 The VirtualGL Project and many others (see README.md)
Visit http://www.TurboVNC.org for more information on TurboVNC

11/06/2025 16:17:11 Enabled security type 'tlsvnc'
11/06/2025 16:17:11 Enabled security type 'tlsotp'
11/06/2025 16:17:11 Enabled security type 'tlsplain'
11/06/2025 16:17:11 Enabled security type 'x509vnc'
11/06/2025 16:17:11 Enabled security type 'x509otp'
11/06/2025 16:17:11 Enabled security type 'x509plain'
11/06/2025 16:17:11 Enabled security type 'vnc'
11/06/2025 16:17:11 Enabled security type 'otp'
11/06/2025 16:17:11 Enabled security type 'unixlogin'
11/06/2025 16:17:11 Enabled security type 'plain'
11/06/2025 16:17:11 Desktop name 'TurboVNC: node20.cluster:1 (jsimms1-swat)' (node20.cluster:1)
11/06/2025 16:17:11 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
11/06/2025 16:17:11 Listening for VNC connections on TCP port 5901
11/06/2025 16:17:11   Interface 0.0.0.0
11/06/2025 16:17:11 Framebuffer: BGRX 8/8/8/8
11/06/2025 16:17:11 New desktop size: 800 x 600
11/06/2025 16:17:11 New screen layout:
11/06/2025 16:17:11   0x00000040 (output 0x00000040): 800x600+0+0
11/06/2025 16:17:11 Maximum clipboard transfer size: 1048576 bytes
(EE) Segmentation fault at address 0x10
(EE) 
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE) 
Could not start Xvnc.
2

How do you provide your TurboVNC? We provide it though a module, which means we build it ourselves.

Did you build it yourself or did you install what epel/RHEL provides? If you built it yourself, I’d suggest rebuilding it. If not, maybe there’s an update you can upgrade to or a version you can rollback to. (I just checked and we run 3.1.1 on our EL9 system, though again, we build it from the source code).

3

Also I would check your old jobs’ logs to see what was different in the old logs from what is now.

As just a spot check, I have a different desktop size than you do.

11/06/2025 16:28:39 New desktop size: 1536 x 864
11/06/2025 16:28:39 New screen layout:
11/06/2025 16:28:39   0x00000040 (output 0x00000040): 1536x864+0+0

Maybe checking older output.logs from older jobs from before you updated your system may provide some insight here.

4

This is from a successful session yesterday:

TurboVNC Server (Xvnc) 64-bit v3.2 (build 20250506)
Copyright (C) 1999-2025 The VirtualGL Project and many others (see README.md)
Visit http://www.TurboVNC.org for more information on TurboVNC

10/06/2025 14:57:57 Enabled security type 'tlsvnc'
10/06/2025 14:57:57 Enabled security type 'tlsotp'
10/06/2025 14:57:57 Enabled security type 'tlsplain'
10/06/2025 14:57:57 Enabled security type 'x509vnc'
10/06/2025 14:57:57 Enabled security type 'x509otp'
10/06/2025 14:57:57 Enabled security type 'x509plain'
10/06/2025 14:57:57 Enabled security type 'vnc'
10/06/2025 14:57:57 Enabled security type 'otp'
10/06/2025 14:57:57 Enabled security type 'unixlogin'
10/06/2025 14:57:57 Enabled security type 'plain'
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
10/06/2025 14:57:57 Desktop name 'TurboVNC: node15.cluster:8 (jsimms1-swat)' (node15.cluster:8)
10/06/2025 14:57:57 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
10/06/2025 14:57:57 Listening for VNC connections on TCP port 5908
10/06/2025 14:57:57   Interface 0.0.0.0
10/06/2025 14:57:57 Framebuffer: BGRX 8/8/8/8
10/06/2025 14:57:57 New desktop size: 800 x 600
10/06/2025 14:57:57 New screen layout:
10/06/2025 14:57:57   0x00000040 (output 0x00000040): 800x600+0+0
10/06/2025 14:57:57 Maximum clipboard transfer size: 1048576 bytes
10/06/2025 14:57:57 VNC extension running!
5

I should also say, we get ours from the standard dnf/yum repo for Rocky 9. So we don’t build ours.

6

Maybe you could manually run vncserver on the node and see if you can generate a core dump to reveal the cause?

7

The problem was that the latest mesa libs result in the segfault. So, for us, the following work:

mesa-*-24.1.2-3.el9

But this version results in a segfault:

mesa-*-24.2.8-2.el9_6

8

Thanks for responding and figuring it out!