Thanks for sharing your thoughts.
If you don't mind, would you be able to share the code changes which helped
to fix this ? I found an issue where avoiding processessing cursor buffers
helped me avoid the deadlock. Something like below code.
/* Sync the state of all layers/buffers */
guac_display_layer* current = display->last_frame.layers;
while (current != NULL) {
/*
* The cursor buffer is handled separately. If it ends up in the main
* layer list, just skip it.
*/
if (current == display->cursor_buffer) {
current = current->last_frame.next;
continue;
}
On Thu, Jan 29, 2026 at 1:38 PM Timpl, Markus <[email protected]>
wrote:
> Hello,
>
> I had a lot of deadlocks/issues with users joining existing connections as
> well(see https://lists.apache.org/thread/3bjbtstq1qln9vgcly3qhkdzvhjzxbbl),
> although it was specifically for RDP but we are also using VNC connections
> with multiple users with the fix.
> What fixed it for me was to acquire the pending_frame.lock in
> guac_display_dup before getting the last_frame.lock and to have the owner
> of the connection never disconnect from the connection. With those changes
> I don’t get any deadlocks on multiple clients connecting and disconnecting
> from the same connection.
>
> I sadly didn’t yet have time to create a JIRA user/issue + MR for the fix.
>
> Best regards,
> *Markus Timpl*
>
> *Von:* Dilip Modi via user <[email protected]>
> *Gesendet:* Mittwoch, 28. Januar 2026 18:26
> *An:* [email protected]
> *Cc:* Dilip Modi <[email protected]>
> *Betreff:* EXT: VNC : User joins existing session gets stuck in
> guac_display_dup
>
>
>
> *EXTERNAL SENDER*
>
> *Caution:* This email originated from outside of Primetals Technologies.
> Please be cautious when clicking links or opening attachments. *Never
> enter username and password unless having verified the source!*
>
>
>
> Hello Guacamole Developers,
>
>
>
> I hope this email finds you well.
>
>
>
> I am using VNC with guacd 1.6.0 version.
>
>
>
> I am finding an issue where user joins VNC session and doesn’t get display
> in browser. This is happening when we run https://giphy.com for display
> frame update.
>
> I'm currently looking into the guacamole-server source code, specifically
> the display synchronization logic in src/libguac/display.c. I have a
> question about the behavior of the guac_display_dup() function.
>
> In this function, there is a call to guac_flag_wait_and_lock() to wait for
> any in-progress frame rendering to complete before synchronizing the
> display for a new user. The comment just above this call says:
>
>
>
>
>
>
>
> */* ... A timeout is used here to avoid blocking indefinitely if a frame
> is already*
>
> ** in progress. */*
>
> guac_flag_wait_and_lock(&display->render_state,
>
> GUAC_DISPLAY_RENDER_STATE_FRAME_NOT_IN_PROGRESS);
>
>
>
> However, from what I can tell, guac_flag_wait_and_lock() seems to be a
> blocking call without a timeout. This could potentially cause
> the guac_display_dup() function to hang indefinitely if
> the GUAC_DISPLAY_RENDER_STATE_FRAME_NOT_IN_PROGRESS flag is never set for
> some reason during an active connection.
>
> Could you please clarify if this is the intended behavior? Perhaps I am
> missing something regarding a timeout mechanism that is implemented
> elsewhere.
>
> Need your input to fix this issue.
>
> Thank you for your time and for all the great work on Guacamole.
>
>
>
> Best regards,
>
> Dilip
>
>
>
>
>
> This communication (including any attachments) is intended for the sole
> use of the intended recipient and may contain confidential, non-public,
> and/or privileged material. Use, distribution, or reproduction of
> this communication by unintended recipients is not authorized. If you
> received this communication in error, please immediately notify the sender
> and then delete all copies of this communication from your system.
>
--
This communication (including any attachments) is intended for the sole
use of the intended recipient and may contain confidential, non-public,
and/or privileged material. Use, distribution, or reproduction of this
communication by unintended recipients is not authorized. If you received
this communication in error, please immediately notify the sender and then
delete all copies of this communication from your system.
