Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Duplicate
-
1.5.4
-
None
-
None
Description
Well, this makes me really happy - all the development and banging on various revisions of 1.5.4, and I run into this bug shortly after approving/merging the website release.
I've managed to hit just the right combination of...something...to run into a segfault during RDP connections using the 1.5.4 code. The segfault appears to be related to the new join handler/synchronization code:
#0 0x00007ffff6fead00 in pthread_mutex_lock () from /lib64/libpthread.so.0 #1 0x0000000000404fa9 in guac_common_list_lock (list=<optimized out>) at list.c:95 #2 0x00007ffff0d5b8a8 in guac_rdp_pipe_svc_send_pipes (client=<optimized out>, socket=0x7fffec0135a0) at channels/pipe-svc.c:51 #3 0x00007ffff0d62440 in guac_rdp_join_pending_handler (client=0x7fffec0145a0) at client.c:126 #4 0x00007ffff7bc12bd in guac_client_promote_pending_users (data=...) at client.c:197 #5 0x00007ffff39edf5f in timer_sigev_thread () from /lib64/librt.so.1 #6 0x00007ffff6fe8ea5 in start_thread () from /lib64/libpthread.so.0 #7 0x00007ffff58e4b0d in clone () from /lib64/libc.so.6
At the moment, it seems to impact RDP connections where I've also enabled SFTP. If I disable the SFTP component, I am able to complete the RDP connection. So, seems like maybe there's some sort of race condition that the SSH/SFTP connection is introducing that causes it to attempt to lock the list prior to it being initialized.
Attachments
Issue Links
- duplicates
-
GUACAMOLE-1140 Starting/joining an RDP connection may segfault depending on timing of underlying RDP/SFTP connection(s)
- Resolved