Regression in 6.6.3: GTK3/GTK4 clients SIGABRT with "xcb_xlib_extra_reply_data_left" under muffin (Mint 22.3 Zena)

[cdhainaut]

Summary

After upgrading muffin 6.6.1+zena → 6.6.3+zena via the zena/backport repo on 2026-04-20, any GTK3 or GTK4 client application consistently SIGABRTs within seconds of opening, with the XCB assertion:

[xcb] Extra reply data still left in queue
[xcb] This is most likely caused by a broken X extension library
[xcb] Aborting, sorry about that.
gnome-calendar: xcb_io.c:627: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed.

Downgrading muffin to 6.6.1 (built from source, tag 6.6.1) with no other changes fully resolves the crashes. Confirmed via session-level WM swap: replacing muffin with metacity --replace eliminates the crashes immediately.

This does not match the open XCB-adjacent issues I found (#807 is a muffin-side XDamageCreate crash under Wine; #817 is a muffin-side xinerama NULL deref on DPMS wake). Here the client crashes, not muffin.

Environment

Distro	Linux Mint 22.3 Zena (Ubuntu noble 24.04 base)
Cinnamon	6.6.7+zena
muffin (bad)	6.6.3+zena
muffin (good)	6.6.1 (built from source)
cinnamon-session	6.6.3+zena
libgtk-4-1	4.14.5+ds-0ubuntu0.10
Mesa	25.2.8-0ubuntu0.24.04.1
Kernel	6.17.0-22-generic (also reproduced on 6.14.0-37)
GPU	AMD Radeon 780M (RDNA-3, Phoenix3)
Session	X11

Affected applications (confirmed)

App	Toolkit	Notes
gnome-calendar	GTK4	4× crashes 2026-04-22 23:02+
simple-scan	GTK4	2× crashes 2026-04-22 23:03+
baobab	GTK4	1× crash 2026-04-21 00:37
nemo	GTK3	5× crashes 2026-04-22, via gdk_drag_find_window_for_screen (XDND)
firefox (libxul)	—	recurring SIGABRT, session-recovery corruption

Stack signature (common top)

libc.so.6       __assert_fail
libX11.so.6     _XReply                       (+ 0x46a45)
libgtk-4.so.1   (GTK4 event / extension call)
  or
libgdk-3.so.0   gdk_drag_find_window_for_screen   (nemo, XDND)

Coredumps available locally for gnome-calendar, nemo, baobab, simple-scan. Happy to attach coredumpctl info output on request.

Reproducer (5 seconds)

# On Mint 22.3 Zena with muffin 6.6.3+zena installed, X11 session, any GTK3/GTK4 app:
gnome-calendar
# → SIGABRT within seconds, xcb_xlib_extra_reply_data_left assertion.

Discrimination tests (rule out unrelated layers)

Test	Result	Conclusion
LIBGL_ALWAYS_SOFTWARE=1 gnome-calendar	same crash	Not Mesa hardware path
GSK_RENDERER=cairo / gl / ngl	same crash	Not a GSK renderer bug
GDK_SYNCHRONIZE=1 gnome-calendar	same crash	Not a race condition
Downgrade libgtk-4-1 0.10 → 0.9	same crash	Not the GTK client library
GTK_IM_MODULE=gtk-im-context-simple XMODIFIERS=""	same crash	Not IBus
Kernel 6.14.0-37 vs 6.17.0-22	same crash	Not kernel
Xephyr :10 -screen 1280x800 &; DISPLAY=:10 gnome-calendar	no crash	Bug lives in the running X compositor (muffin)
metacity --replace replacing muffin in the live session	no crash	Confirms: muffin 6.6.3 is the emitter
Downgrade muffin 6.6.3 → 6.6.1 (source build, same cinnamon-session/GTK/Mesa)	no crash across 5 GTK apps + firefox post-reboot	Root cause confirmed

Hypothesis

The XCB Extra reply data still left in queue assertion is triggered client-side when a reply to an X extension request contains more data than the reply handler consumes. In an X11 session the compositor mediates several extensions (XFixes for cursor/clipboard, Damage/Composite for drawing, XDND via selection events…). A muffin change in 6.6.3 in one of those reply paths most likely leaves extra bytes on the wire for specific requests, tripping XCB in every client that queries the affected extension.

I haven't localized the offending commit in the 6.6.1 → 6.6.3 delta yet. If helpful I can bisect against the source tree.

Timeline

Date/time (local)	Event
2026-04-20 13:20	apt upgrade: muffin 6.6.1 → 6.6.3, cinnamon 6.6.4 → 6.6.7, Mesa 25.0.7 → 25.2.8, libc6, libinput, systemd, firefox (bulk Mint Zena backport sync)
2026-04-21 00:37	First crash: baobab
2026-04-22 13:38	Crashes cascade: nemo, gnome-calendar, simple-scan, firefox
2026-04-23	Built muffin 6.6.1 from source (tag 6.6.1), apt-mark hold muffin muffin-common libmuffin0 gir1.2-meta-muffin-0.0, zero crashes since

Workaround

Downgrade muffin to 6.6.1. Build from source:

git clone https://github.com/linuxmint/muffin && cd muffin
git checkout 6.6.1
# build instructions per debian/ rules on a Mint 22.3 box
sudo dpkg -i muffin_6.6.1+local1_amd64.deb muffin-common_6.6.1+local1_all.deb \
             libmuffin0_6.6.1+local1_amd64.deb gir1.2-meta-muffin-0.0_6.6.1+local1_amd64.deb
sudo apt-mark hold muffin muffin-common libmuffin0 gir1.2-meta-muffin-0.0

The 6.6.1+zena .deb packages are no longer available from packages.linuxmint.com or in APT cache.

What I can provide on request

• Full coredumpctl info dumps for gnome-calendar / nemo / baobab / simple-scan
• xdpyinfo -queryExtensions output before/after muffin downgrade
• Full apt log of the 2026-04-20 upgrade (~200 packages)
• xtrace of a crashing gnome-calendar startup to pin the malformed extension reply

Happy to bisect 6.6.1 → 6.6.3 if no one has a faster pointer.

[mtwebster]

There are 2 substantive commits between 6.6.1 and 6.6.3:

98298ea (Revert 98298ea - ignore XkbNewKeyboardNotify...)
070ef01 (display.c: Exclude 'always on top' windows from the monitor)

The second one is highly unlikely to be related. The first is also doubtful.

I haven't experienced any of these crashes. I use gnome-calendar often. I've never seen this in nemo, I use that constantly.

Have you:

• Tried building 6.6.3 from source (I notice you're only building 6.6.1, but using the system's 6.6.3 - how are you building? With dpkg-buildpackage or straight meson?
• Tried on another machine
• Tried with a 'fresh' user account on that system

If this was a wide-ranging bug we'd have had reports of it before now, so I'm a bit suspicious of the data.