It looks like when I did the recompile of 1.2.0 server, libvnc didn’t get updated. I copied those over from another 1.2.0 installation, restarted guacd and tomcat, and now VNC works properly. Not sure why it didn’t get updated, but we’re good now.
Thanks, Harry From: Mike Jumper <mjum...@apache.org> Sent: Wednesday, August 19, 2020 3:17 PM To: user@guacamole.apache.org Subject: Re: Segfault with VNC on 1.2.0 On Wed, Aug 19, 2020 at 8:21 AM Devine, Harry (FAA) <harry.dev...@faa.gov.invalid<mailto:harry.dev...@faa.gov.invalid>> wrote: Our users are reporting segmentation faults since we upgraded to 1.2.0 yesterday in regards to VNC: Aug 18 14:20:31 access guacd[15386]: VNC server supports protocol version 3.8 (viewer 3.8) Aug 18 14:20:31 access guacd[15386]: We have 1 security types to read Aug 18 14:20:31 access guacd[15386]: 0) Received security type 1 Aug 18 14:20:31 access guacd[15386]: Selecting security type 1 (0/1 in the list) Aug 18 14:20:31 access guacd[15386]: Selected Security Scheme 1 Aug 18 14:20:31 access guacd[15386]: No authentication needed Aug 18 14:20:31 access guacd[15386]: VNC authentication succeeded Aug 18 14:20:31 access guacd[15386]: Desktop name "Display_25" Aug 18 14:20:31 access guacd[15386]: Connected to VNC server, using protocol version 3.8 Aug 18 14:20:31 access guacd[15386]: VNC server default format: Aug 18 14:20:31 access guacd[15386]: 32 bits per pixel. Aug 18 14:20:31 access guacd[15386]: Least significant byte first in each pixel. Aug 18 14:20:31 access guacd[15386]: TRUE colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Aug 18 14:20:33 access dbus[1231]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' Aug 18 14:20:33 access systemd: Starting Hostname Service... Aug 18 14:20:33 access dbus[1231]: [system] Successfully activated service 'org.freedesktop.hostname1' Aug 18 14:20:33 access systemd: Started Hostname Service. Aug 18 14:20:50 access kernel: guacd[15400]: segfault at 1 ip 00007ff42a0f0faf sp 00007ff425605c18 error 4 in libc-2.17.so<http://libc-2.17.so>[7ff42a056000+1c3000] Aug 18 14:20:50 access abrt-hook-ccpp: Process 15386 (guacd) of user 0 killed by SIGSEGV - dumping core Aug 18 14:20:51 access guacd[31477]: Connection "$d368bfac-36a2-421d-91f1-9c640da8ed34" removed. They want us to fall back but is there a way we can find out what’s going on? If you can reliably reproduce this, the thing to do would be: 1) Attach gdb to the main guacd process (execution of guacd will be temporarily suspended) 2) (gdb) set follow-fork-mode child 3) (gdb) continue gdb will then resume guacd, and will automatically debug the process that is forked to handle the next connection that comes in. After that happens, if the segfault occurs, gdb will suspend the affected connection process and you can obtain a stack trace of all threads: 4) (gdb) thread apply all bt Depending on what specifically is happening, you may need to install the debug symbols for other libraries on your system to get a more meaningful stack trace. - Mike
