Package: gnome-shell
Version: 50.3-1
Severity: important
-- Summary --
gnome-shell repeatedly crashes with SIGSEGV inside libibus-1.0's GObject
signal-emission path (g_signal_emit -> libibus ??? -> g_object_unref ->
g_type_check_instance_is_fundamentally_a), specifically while composing a
dead-key character (Czech ď/ť/ň via a caron dead key) in an X11 client
running under Xwayland (rxvt-unicode / urxvt). The crash brings down the
whole gnome-session (OnFailure= cascade tears down graphical-session.target),
which looks to the user like being logged out.
Reproduced twice with full coredumps (systemd-coredump), same crashing
frame both times:
#0 g_type_check_instance_is_fundamentally_a () [libgobject-2.0.so.0]
#1 g_object_unref () [libgobject-2.0.so.0]
#2 ??? () [libibus-1.0.so.5]
#3 g_closure_invoke () [libgobject-2.0.so.0]
#4 (closure marshal, glib internal) [libgobject-2.0.so.0]
#5 (closure marshal, glib internal) [libgobject-2.0.so.0]
#6 g_signal_emit_valist () [libgobject-2.0.so.0]
#7 g_signal_emit () [libgobject-2.0.so.0]
#8 ??? () [libibus-1.0.so.5]
#9 g_object_unref () [libgobject-2.0.so.0]
#10-12 (gnome-shell JS/IBus glue) [libgjs.so.0]
... (JS engine / libmozjs frames) ...
#28 meta_context_run_main_loop () [libmutter-18.so.0]
... (gjs bootstrap) ...
libibus-1.0.so.5 was stripped, so frames #2 and #8 could not be resolved to
function names even via debuginfod.debian.net (no debug info available
there for this build). Filing against gnome-shell since that is the
crashing process (gjs/mutter's own IBus panel/input-method integration
appears to hold a second libibus connection independent of the ibus-x11 XIM
bridge used by the X11 client itself); please reassign to libibus1.0 if the
maintainers judge the bug to actually live there.
-- Reproduction --
1. Session: GNOME on Wayland (mutter/gnome-shell compositor), input source
configured as plain xkb:cz (org.gnome.desktop.input-sources sources =
[('xkb', 'cz')], no explicit ibus engine selected). GNOME nonetheless
runs ibus-daemon, ibus-x11, ibus-engine-simple, ibus-extension-gtk3 in
the background for every session, and sets XMODIFIERS=@im=ibus session-
wide, QT_IM_MODULE=ibus.
2. Open an X11 client that uses Xlib's own XIM (not GTK's IM framework) -
rxvt-unicode (urxvt) - under Xwayland.
3. Type a dead-key composed character, e.g. the caron dead key (physically
located next to '=' on a Czech keyboard) followed by 'd', 't' or 'n', to
produce ď/ť/ň. This routes: physical key -> Xwayland -> XIM protocol ->
ibus-x11 -> ibus-daemon -> ibus-engine-simple (composing state) ->
preedit/commit signals broadcast over the session IBus bus.
4. Intermittently (not every time - seems load/timing dependent, i.e. a
race), gnome-shell itself (which also holds an IBus connection, used to
render the composing/candidate popup and the input-source indicator)
crashes with SIGSEGV in the frame shown above, right as the dead-key
composition signals are firing.
5. gnome-shell's crash triggers [email protected]'s OnFailure=
dependency chain, which stops graphical-session.target and effectively
tears down the whole GNOME session - every other app loses its Wayland/
X11 connection at the same moment (nautilus, gnome-terminal, urxvt,
chrome, etc. all log "Lost connection to Wayland compositor" / "X
connection to ':0' broken" within the same second). From the user's
point of view this looks exactly like being abruptly logged out.
-- Evidence from journalctl / coredumpctl (second occurrence) --
$ coredumpctl list gnome-shell
Fri 2026-09-04 10:33:07 CEST 500239 1000 1000 SIGSEGV present
/usr/bin/gnome-shell 52.5M
$ coredumpctl info 500239
Signal: 11 (SEGV) si_code: SEGV_MAPERR
Unit: [email protected] / User Unit: [email protected]
Journal right before the crash shows a KMS/DRM page-flip failure and an
audio device hot-unplug a few seconds earlier in the FIRST occurrence
(2026-09-02 14:57:19), which looked initially like the trigger, but this
SECOND occurrence (2026-09-04 10:33) happened with no such hardware event
at all - the only common factor between the two crashes is dead-key
diacritic composition in urxvt immediately beforehand, and the identical
crashing frame in libibus's g_object_unref/g_signal_emit path. This
strongly suggests the actual bug is a use-after-free / refcounting race in
libibus (an IBusObject or similar being unreffed while a signal on it is
still being emitted/marshalled), which the DRM/audio event on the first
occurrence at most only made more likely to lose the race, rather than
being the direct cause.
-- System information --
Debian release: forky/sid (13.x)
Kernel: Linux ideapad 7.1.8+deb14.1-amd64 #1 SMP PREEMPT_DYNAMIC Debian
7.1.8-2 (2026-08-15) x86_64
Versions of packages involved:
ii gnome-shell 50.3-1 (50.4-1 available, changelog does not
mention any ibus/segv related fix)
ii libmutter-18-0 50.3-1
ii libibus-1.0-5 1.5.34-1
ii ibus-data 1.5.34-1
-- What I tried --
- systemd-coredump is installed; both crashes produced full, non-truncated
coredumps, so a backtrace was obtainable via
`coredumpctl debug /usr/bin/gnome-shell -1 -A "-batch -ex bt"`.
- Tried `set debuginfod enabled on` with DEBUGINFOD_URLS=
https://debuginfod.debian.net to resolve the libibus frames - no debug
info was found there for libibus-1.0-5, so frames #2/#8 remain unresolved
addresses. Happy to attach the full coredump or run further gdb commands
against it (`info registers`, `disassemble`, `p *(IBusObject*)...` etc.)
if that would help triage - it is still on disk.
- As a workaround, I am now launching urxvt with XMODIFIERS= (empty), so it
uses libX11's built-in Compose engine (~/.XCompose) instead of going
through the ibus-x11 XIM bridge, which should avoid exercising this code
path for that client. Have not yet had enough uptime to confirm this
prevents the crash long-term.
-- Attachments available on request --
- Full gdb backtrace (all threads) from both coredumps.
- The two coredump files themselves (~52 MB / ~size of first, both under
/var/lib/systemd/coredump/ while retained).
--
Ondřej Tůma <[email protected]>
https://ipv6.mcbig.cz https://keybase.io/mcbig twitter: mcbig_cz
