Cinnamon 6.4.14 event loop wedges after X11 overlay/window automation while Xorg stays responsive

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:

1. Log into a Cinnamon X11 session.
2. Start cua-driver 0.19.2 with its default X11 overlay enabled.
3. Use it to snapshot windows and issue an EWMH bring-to-front operation; in the second run a terminal launch followed.
4. Continue probing both layers every minute:
   • xset q for Xorg.
   • a five-second timeout around org.Cinnamon.Eval('1+1') for Cinnamon.
5. 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.

Reproduce this only in an isolated nested compositor or disposable X11 session, using xset q and the timeout-bounded org.Cinnamon.Eval('1+1') probe to distinguish Xorg from Cinnamon failure. Capture the requested debugger stack or targeted instrumentation around the Cinnamon/Muffin X11 event path, especially overlay, accessibility, activation, and launch operations. Done means identifying the blocking path and keeping Cinnamon's event loop responsive during the trigger sequence.