osu! segfault in libX11.so when IM daemon exits and window regains focus (X11)

Type

Crash to desktop

Bug description

Application-Specific IM Error Handling: IM Daemon Crash/Exit While Window is Backgrounded

Environment:

• OS: Linux Mint 22.3 - Cinnamon 64-bit
• Kernel: 6.14.0-37-generic
• osu! version: 2026.711.0-lazer (Flatpak), 2026.726.0-lazer (Flatpak & AppImage)
• Display Server: X11
• Mesa: 25.2.8
• Input method framework: IBus

Steps to reproduce:

1. Start fcitx5 input method / ibus-daemon
2. Start osu! (Flatpak / AppImage)
3. Exit fcitx5 / pkill fcitx5 / pkill ibus-daemon while osu! is running
4. Alt+Tab to switch windows back to osu! → Segfault
   Note: Starting osu! before fcitx5 / ibus-daemon does not trigger the crash, confirming the issue is in osu!'s IM context binding and cleanup logic.

Expected behavior:
No crash; graceful IM cleanup when fcitx5 / ibus-daemon exits

Actual behavior:
osu! segfaults in libX11.so.6.4.0 when window regains focus after fcitx5 / ibus-daemon termination (stack trace shows IM event handling)

Workaround (confirmed working):
Launch osu! with: flatpak run --env=GTK_IM_MODULE=none --env=QT_IM_MODULE=none --env=XMODIFIERS= sh.ppy.osu
Launch Steam with: flatpak run --env=GTK_IM_MODULE=none --env=QT_IM_MODULE=none --env=XMODIFIERS= com.valvesoftware.Steam
or just launch osu! before fcitx5 / ibus-daemon does.
Note: Steam exhibits a related but distinct issue — it does not crash immediately when window regains focus, but segfaults on exit without displaying the normal exit popup. This suggests a different crash point in the IM context cleanup chain.

The X11 IM module fails to gracefully handle IM daemon termination when the IM context is still active. Disabling IM modules entirely prevents both crashes, confirming the root cause lies in IM context handling.

Additional observations:

• Observed one spontaneous segfault in libbassmix.so (GameThread[3164]) during idle, resulting in core dump, but unable to reproduce consistently.

Screenshots or videos

Not applicable — issue is reliably reproducible following the provided steps.

Version

2026.711.0-lazer (Flatpak), 2026.726.0-lazer (Flatpak & AppImage)

Logs

gnome-terminal-[13429]: Unable to connect to ibus: The given address is empty
kernel: osu![19249]: segfault at 571e734de245 ip 000076f775f091c3 sp 00007ffd54e7f8a8 error 4 in libX11.so.6.4.0[5a1c3,76f775ecd000+99000] likely on CPU 4 (core 8, socket 0)
kernel: Code: 41 5c 41 5d 5d c3 e8 9c 73 fc ff 90 66 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 85 ff 74 17 48 83 7f 08 00 74 10 48 8b 07 <ff> 60 08 66 2e 0f 1f 84 00 00 00 00 00 c3 0f 1f 40 00 66 66 2e 0f
systemd[1]: Started systemd-coredump@2-19410-0.service - Process Core Dump (PID 19410/UID 0).
(sd-parse-elf)[19417]: Could not parse number of program headers from core file: invalid `Elf' handle
(sd-parse-elf)[19417]: Could not parse number of program headers from core file: invalid `Elf' handle
(sd-parse-elf)[19417]: Could not parse number of program headers from core file: invalid `Elf' handle
(sd-parse-elf)[19417]: Could not parse number of program headers from core file: invalid `Elf' handle
(sd-parse-elf)[19417]: Could not parse number of program headers from core file: invalid `Elf' handle
systemd-coredump[19411]: [🡕] Process 19249 (osu!) of user 1000 dumped core.
                                              
                                              Module /app/bin/libbassmix.so without build-id.
                                              Module /app/bin/libbassmix.so
                                              Module /app/bin/librealm-wrappers.so without build-id.
                                              Module /app/bin/librealm-wrappers.so
                                              Module /app/bin/libbass_fx.so without build-id.
                                              Module /app/bin/libbass_fx.so
                                              Module /app/bin/libSDL3.so without build-id.
                                              Module /app/bin/libSDL3.so
                                              Module /app/bin/libbass.so without build-id.
                                              Module /app/bin/libbass.so
                                              Stack trace of thread 2:
                                              #0  0x000076f775f091c3 n/a (/usr/lib/x86_64-linux-gnu/libX11.so.6.4.0 + 0x5a1c3)
                                              ELF object binary architecture: AMD x86-64
systemd[1]: systemd-coredump@2-19410-0.service: Deactivated successfully.

Confirmed the issue persists in 2026.726.0-lazer (Flatpak & AppImage).
Reproduced it following the steps above, and the workaround is still effective.

Root Cause Analysis: IM Daemon Termination Handling

The root cause is not D-Bus unavailability, but osu! and Steam's failure to gracefully handle IM daemon termination:

Evidence:

Other X11 applications handle IM daemon exit gracefully:

• apt (gnome-terminal, Celluloid): No crash
• Flatpak (OBS Studio, LMMS, KeePassXC): No crash
• Flatpak (osu!, Steam): Segfault in libX11.so IM layer

AppImage behaves identically to Flatpak:

• Official osu! AppImage: Same segfault with identical trigger sequence
• This confirms the issue is application-level code, not Flatpak sandboxing

Root Cause:

When fcitx5 / ibus-daemon exits, osu! and Steam retain a dangling IM context pointer. When the window subsequently regains focus on osu!, XSetICFocus attempts to access this corrupted context → segfault in libX11.so.6.4.0.

Other applications likely implement:

• Monitoring IM daemon status via D-Bus signals
• Cleaning up IM context on daemon termination
• Fallback to XIM or disabling IM on error

Workaround: Disable IM modules entirely

GTK_IM_MODULE=none QT_IM_MODULE=none XMODIFIERS= ./osu.AppImage
flatpak run --env=GTK_IM_MODULE=none --env=QT_IM_MODULE=none --env=XMODIFIERS= sh.ppy.osu

Offical AppImage Verification

After downloading the latest AppImage release on the README page (https://github.com/ppy/osu/releases/latest/download/osu.AppImage), reproduce those steps above also caused segfault.

Logs

gnome-terminal-[19902]: Unable to connect to ibus: The given address is empty
kernel: osu![28608]: segfault at 577fd0289a35 ip 00007df5efb11c93 sp 00007ffe2063d0d8 error 4 in libX11.so.6.4.0[4ec93,7df5efadc000+90000] likely on CPU 7 (core 11, socket 0)
kernel: Code: 5b 41 5c 41 5d 5d c3 e8 8b ae fc ff 66 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 85 ff 74 17 48 83 7f 08 00 74 10 48 8b 07 <ff> 60 08 66 2e 0f 1f 84 00 00 00 00 00 c3 66 66 2e 0f 1f 84 00 00
systemd[1]: Started systemd-coredump@4-28744-0.service - Process Core Dump (PID 28744/UID 0).
(sd-parse-elf)[28746]: Could not parse number of program headers from core file: invalid `Elf' handle
(sd-parse-elf)[28746]: Could not parse number of program headers from core file: invalid `Elf' handle
(sd-parse-elf)[28746]: Could not parse number of program headers from core file: invalid `Elf' handle
(sd-parse-elf)[28746]: Could not parse number of program headers from core file: invalid `Elf' handle
(sd-parse-elf)[28746]: Could not parse number of program headers from core file: invalid `Elf' handle
systemd-coredump[28745]: [🡕] Process 28608 (osu!) of user 1000 dumped core.
                                              
                                              Module /tmp/.mount_osu.ApcFVQrD/usr/bin/libbassmix.so without build-id.
                                              Module /tmp/.mount_osu.ApcFVQrD/usr/bin/libbassmix.so
                                              Module /tmp/.mount_osu.ApcFVQrD/usr/bin/librealm-wrappers.so without build-id.
                                              Module /tmp/.mount_osu.ApcFVQrD/usr/bin/librealm-wrappers.so
                                              Module /tmp/.mount_osu.ApcFVQrD/usr/bin/libbass_fx.so without build-id.
                                              Module /tmp/.mount_osu.ApcFVQrD/usr/bin/libbass_fx.so
                                              Module /tmp/.mount_osu.ApcFVQrD/usr/bin/libSDL3.so without build-id.
                                              Module /tmp/.mount_osu.ApcFVQrD/usr/bin/libSDL3.so
                                              Module /tmp/.mount_osu.ApcFVQrD/usr/bin/libbass.so without build-id.
                                              Module /tmp/.mount_osu.ApcFVQrD/usr/bin/libbass.so
                                              Module libudev.so.1 from deb systemd-255.4-1ubuntu8.16.amd64
                                              Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2build1.1.amd64
                                              Module libsystemd.so.0 from deb systemd-255.4-1ubuntu8.16.amd64
                                              Module libgcc_s.so.1 from deb gcc-14-14.2.0-4ubuntu2~24.04.1.amd64
                                              Module libstdc++.so.6 from deb gcc-14-14.2.0-4ubuntu2~24.04.1.amd64
                                              Stack trace of thread 28608:
                                              #0  0x00007df5efb11c93 XSetICFocus (libX11.so.6 + 0x4ec93)
                                              #1  0x00007df5efdffbea n/a (/tmp/.mount_osu.ApcFVQrD/usr/bin/libSDL3.so + 0x1ffbea)
                                              ELF object binary architecture: AMD x86-64
systemd[1]: systemd-coredump@4-28744-0.service: Deactivated successfully.

Update: Tested with ibus-daemon instead of fcitx5.
Reproduction sequence: ibus-daemon -drx → osu! → pkill ibus-daemon → window regains focus
Result: Segfault

This confirms the issue occurs with any IM daemon, not just fcitx5.

Also reported the same issue affecting Steam here: ValveSoftware/steam-for-linux#13457

Both stem from use-after-free access to cached X11 IM context pointers when the window regains focus after IM daemon termination. However, the crash occurs at different locations:

• osu!: libX11.so at XSetICFocus
• Steam: steamui.so (independent crashes in both steamwebhelper and main process)

[Kontrabant]

Should be fixed upstream in libsdl-org/SDL#16076

libsdl-org/SDL#16076 addresses this for SDL-based applications, but osu! calls libX11 directly without SDL. A similar IC destroyed callback registration would need to be implemented in osu!'s code to handle ibus/fcitx termination.

[longnguyen2004]

A lot of AI slop...osu! does in fact use SDL