[
https://issues.apache.org/jira/browse/GUACAMOLE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794509#comment-17794509
]
Mike Jumper commented on GUACAMOLE-1890:
----------------------------------------
This sounds to me like a race condition in the allocation of
{{rdp_client->available_svc}}, where enabling SFTP makes the connection process
take _just_ long enough to cause {{guac_rdp_pipe_svc_send_pipes()}} to be
called too early. There is an overall lock on {{rdp_client}} - I'm not sure why
we're not locking that in {{guac_rdp_join_pending_handler}}. [~jmuehlner], do
you remember if there was a reason we can't acquire the lock?
Either way, there should probably be a {{NULL}} check around
{{rdp_client->available_svc}} ... either within
{{guac_rdp_pipe_svc_send_pipes()}} or within the join pending handler.
> 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)
