Distribution
Linux Mint 22.2 Zara, Cinnamon edition, X11 session.
Package version
- Cinnamon 6.4.14 (
6.4.14+xia)
- Muffin 6.4.1
xserver-xorg-core 21.1.12 (2:21.1.12-1ubuntu1.6)- Kernel 6.8.0-137-generic
- Mesa 25.2.8
Graphics hardware in use
Dual AMD GPU system:
- Primary: Radeon RX 7900 XT / Navi 31 (
amdgpu, DisplayPort, 3840x2160 at 60 Hz)
- Integrated: AMD Raphael / RDNA 2 (
amdgpu, no active output)
Frequency
Quite often. The specific third-party X11 automation sequence below was followed by the same Cinnamon-only hang twice consecutively on 2026-08-18. Similar Cinnamon-only hangs have also occurred without that tool, so I am reporting it as a strong trigger, not claiming it is the universal root cause.
Bug description
Cinnamon's event loop stops servicing repaint, input, and D-Bus while Xorg remains responsive. A text VT and the rest of the host continue working. xset q against display :0 returns promptly, but a timeout-bounded org.Cinnamon.Eval('1+1') call does not return within five seconds.
Both recent occurrences followed startup of cua-driver 0.19.2, a third-party native GUI automation tool that creates an X11 cursor overlay and performs accessibility/window operations. The driver emitted this warning when its overlay initialized:
WARN platform_linux::overlay: X11 overlay: root reads cannot see this window's own pixels; save-unders will be served without readback confirmation
First occurrence:
- 19:50:57.998 AEST:
cua-driver serve invoked.
- 19:51:01.149: liveness control was healthy:
OK x_rc=0 cinnamon_rc=0.
- 19:52:07.184: first failure:
CINNAMON_WEDGED x_rc=0 cinnamon_rc=124.
Second occurrence, after Cinnamon had been replaced and verified healthy:
- 20:06:00.851: the CUA X11 overlay initialized.
- 20:06:15.159: healthy control:
OK x_rc=0 cinnamon_rc=0.
- 20:06:20-20:07:15: the tool took window snapshots, sent a bring-to-front request, and launched a terminal window.
- 20:07:20.950: first failure:
CINNAMON_WEDGED x_rc=0 cinnamon_rc=124.
- The same signature repeated at 20:08 and 20:09 until Cinnamon was replaced.
During both failures:
- Xorg remained responsive and continued context switching.
- AMDGPU interrupt activity continued at approximately 60 interrupts/second.
- GPU busy was 0% at the failed probes.
- Cinnamon remained alive with 34-37 file descriptors; its main thread waited in
do_poll, and helper threads predominantly waited in futex_wait_queue.
- Cinnamon ignored
SIGTERM while wedged.
- There was no kernel panic, OOM event, GPU reset, ring timeout, hung task, storage error, or coredump.
- Memory, swap, and filesystem capacity were healthy.
Replacing only Cinnamon restored the existing graphical session; Xorg and user applications did not need to be restarted.
Steps to reproduce
This has wedged the live desktop repeatedly, so I am not re-running it there. The observed sequence was:
- Log into a Cinnamon X11 session.
- Start
cua-driver 0.19.2 with its default X11 overlay enabled.
- Use it to snapshot windows and issue an EWMH bring-to-front operation; in the second run a terminal launch followed.
- Continue probing both layers every minute:
xset q for Xorg.- a five-second timeout around
org.Cinnamon.Eval('1+1') for Cinnamon.
- Within approximately 70-80 seconds, Cinnamon stops responding while the Xorg probe continues to pass.
The tool's source repository is https://github.com/trycua/cua. I can reproduce further only in an isolated nested compositor or disposable login session with a debugger attached first.
Expected behavior
Cinnamon/Muffin should continue servicing its main loop when an X11 client creates an overlay, performs accessibility operations, sends an activation request, or launches another client. Invalid or unsupported EWMH/overlay behavior should be rejected without blocking the compositor/event loop.
Additional information
During the affected session, .xsession-errors also recorded:
Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0
Window manager warning: Attempt to perform window operation 1 on window ... when operation 1 ... already in effect
Those warnings are temporally relevant but are not yet proven to be the blocking call.
No third-party Cinnamon extensions were enabled. Standard Cinnamon applets were in use.
The same host has had less frequent Cinnamon-only hangs without cua-driver. That rules out the automation tool as a necessary cause, but two consecutive healthy-control-to-hang sequences make its overlay/window path a useful deterministic trigger for investigating the underlying Cinnamon/Muffin event-loop failure.
There is no userspace stack yet because Yama denied debugger attachment and the Xorg process is root-owned. I can add targeted instrumentation or a stack trace from an isolated reproduction if maintainers can advise which Cinnamon/Muffin thread or X11 event path would be most useful.
Distribution
Linux Mint 22.2 Zara, Cinnamon edition, X11 session.
Package version
6.4.14+xia)xserver-xorg-core21.1.12 (2:21.1.12-1ubuntu1.6)Graphics hardware in use
Dual AMD GPU system:
amdgpu, DisplayPort, 3840x2160 at 60 Hz)amdgpu, no active output)Frequency
Quite often. The specific third-party X11 automation sequence below was followed by the same Cinnamon-only hang twice consecutively on 2026-08-18. Similar Cinnamon-only hangs have also occurred without that tool, so I am reporting it as a strong trigger, not claiming it is the universal root cause.
Bug description
Cinnamon's event loop stops servicing repaint, input, and D-Bus while Xorg remains responsive. A text VT and the rest of the host continue working.
xset qagainst display:0returns promptly, but a timeout-boundedorg.Cinnamon.Eval('1+1')call does not return within five seconds.Both recent occurrences followed startup of
cua-driver0.19.2, a third-party native GUI automation tool that creates an X11 cursor overlay and performs accessibility/window operations. The driver emitted this warning when its overlay initialized:First occurrence:
cua-driver serveinvoked.OK x_rc=0 cinnamon_rc=0.CINNAMON_WEDGED x_rc=0 cinnamon_rc=124.Second occurrence, after Cinnamon had been replaced and verified healthy:
OK x_rc=0 cinnamon_rc=0.CINNAMON_WEDGED x_rc=0 cinnamon_rc=124.During both failures:
do_poll, and helper threads predominantly waited infutex_wait_queue.SIGTERMwhile wedged.Replacing only Cinnamon restored the existing graphical session; Xorg and user applications did not need to be restarted.
Steps to reproduce
This has wedged the live desktop repeatedly, so I am not re-running it there. The observed sequence was:
cua-driver0.19.2 with its default X11 overlay enabled.xset qfor Xorg.org.Cinnamon.Eval('1+1')for Cinnamon.The tool's source repository is https://github.com/trycua/cua. I can reproduce further only in an isolated nested compositor or disposable login session with a debugger attached first.
Expected behavior
Cinnamon/Muffin should continue servicing its main loop when an X11 client creates an overlay, performs accessibility operations, sends an activation request, or launches another client. Invalid or unsupported EWMH/overlay behavior should be rejected without blocking the compositor/event loop.
Additional information
During the affected session,
.xsession-errorsalso recorded:Those warnings are temporally relevant but are not yet proven to be the blocking call.
No third-party Cinnamon extensions were enabled. Standard Cinnamon applets were in use.
The same host has had less frequent Cinnamon-only hangs without
cua-driver. That rules out the automation tool as a necessary cause, but two consecutive healthy-control-to-hang sequences make its overlay/window path a useful deterministic trigger for investigating the underlying Cinnamon/Muffin event-loop failure.There is no userspace stack yet because Yama denied debugger attachment and the Xorg process is root-owned. I can add targeted instrumentation or a stack trace from an isolated reproduction if maintainers can advise which Cinnamon/Muffin thread or X11 event path would be most useful.