[
https://issues.apache.org/jira/browse/GUACAMOLE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman updated GUACAMOLE-1890:
-------------------------------------
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:
{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
{code}
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.
was:
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:
{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
{code}
At the moment, it only seems to impact connections to xrdp-based servers - I'm
able to connect to Windows Server 2012, 2016, and 2019 without issues, and when
I track down a Server 2022 system I'll verify that. The two xrdp-based systems
- one on EL7 and one EL8 - that I've tried both hit this condition.
> Segfault in RDP Connection Pending Join Handler
> -----------------------------------------------
>
> Key: GUACAMOLE-1890
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1890
> Project: Guacamole
> Issue Type: Improvement
> Components: RDP
> Affects Versions: 1.5.4
> Reporter: Nick Couchman
> Priority: Major
>
> 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:
> {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
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
