You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@guacamole.apache.org by "Nick Couchman (Jira)" <ji...@apache.org> on 2026/08/22 20:09:00 UTC
[jira] [Closed] (GUACAMOLE-2321) guacd 1.6.0: GUAC_ASSERT failure in guac_display_remove_layer() (display-layer-list.c:327) terminates active RDP connections
[ https://issues.apache.org/jira/browse/GUACAMOLE-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Couchman closed GUACAMOLE-2321.
------------------------------------
Resolution: Duplicate
This appears to be a duplicate of GUACAMOLE-2118, as the in-question GUAC_ASSERT call is the same one identified in one of the stack traces pulled for that issue.
> guacd 1.6.0: GUAC_ASSERT failure in guac_display_remove_layer() (display-layer-list.c:327) terminates active RDP connections
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: GUACAMOLE-2321
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-2321
> Project: Guacamole
> Issue Type: Bug
> Environment: guacd 1.6.0 (official image guacamole/guacd:1.6.0, Alpine base)
> guacamole-client 1.6.0 (guacamole/guacamole:1.6.0)
> Protocol: RDP
> Deployment: Docker, guacd and client in separate containers
> Reporter: Diederick Stoffers
> Priority: Major
>
> Since upgrading to 1.6.0, guacd intermittently aborts the connection
> handler for an active RDP session with:
> GUAC_ASSERT in guac_display_remove_layer() failed at display-layer-list.c:327.
> The assertion is always immediately followed by the connection being torn
> down, e.g.:
> GUAC_ASSERT in guac_display_remove_layer() failed at display-layer-list.c:327.
> guacd[1]: INFO: Connection "$33598ecb-d41f-48ea-b8e8-24b0c98b9dff" removed.
> guacd[1]: INFO: Creating new client for protocol "rdp"
> From the user's point of view the RDP session simply disappears and must
> be reconnected. Because guacd forks per connection, only the child process
> dies -- the guacd container itself stays up with a passing healthcheck, so
> the failure is invisible to ordinary process-level monitoring.
> Observed 7 times across 5 distinct days on a single guacd instance:
> 2026-08-16 22:52:57
> 2026-08-18 09:26:55, 09:27:25, 09:29:17, 10:43:16
> 2026-08-19 12:27:42
> 2026-08-20 09:42:28
> The cluster on 2026-08-18 (three failures within ~2.5 minutes) appears to
> be a user reconnecting and hitting the same fault repeatedly.
> Six of the seven occurrences terminated the connection immediately. In the
> remaining case the same connection continued logging afterwards.
> A possibly relevant correlation: the majority of occurrences are preceded
> by repeated CLIPRDR warnings on the same connection:
> guacd[8]: WARNING: Received clipboard data cannot be sent to the RDP
> server because the RDP server has requested a clipboard format which
> was not declared as available. This violates the specification for the
> CLIPRDR channel.
> Not all occurrences have this preamble -- one follows normal RDPDR device
> redirection activity ("RDPDR user logged on") instead -- so clipboard
> activity may be coincidental rather than causal. Flagging it in case the
> layer lifecycle and the clipboard channel interact.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)