mangoapp + KDE session-helper crash-loop on splitscreen launch (Framework Desktop, docked 2-player) — regression, worked ~1-2mo ago

[aradanmn]

Summary

Splitscreen Minecraft failed to load on the Framework Desktop (not the Steam Deck this repo targets) on 2026-09-26 evening. Reported working ~1-2 months ago on this same box; broken now. Root cause is not in this repo's own logic — the orchestrator gets through controller-slot setup correctly both times, then the surrounding Bazzite session infrastructure (mangoapp + several KDE Plasma helper services) goes into a crash loop.

Environment

• Host: Framework Desktop (Ryzen AI Max 385, AMD Radeon 8050S / RADV STRIX_HALO iGPU) — 2-controller docked mode (Wireless Controller + 8BitDo Ultimate 2), not the Steam Deck
• OS image at time of failure: ghcr.io/ublue-os/bazzite-deck:stable 44.20260921 (in place continuously since 2026-09-21, unrelated reboot cycle earlier that same evening did not change this deployment)
• terra-mangohud 0.8.4-2.fc44, mesa-filesystem 26.2.2-3.fc44, kcgroups-dmemcg 0.1-2.fc44, uresourced 0.5.4-5.fc44 — all installed 2026-09-20/21 as part of that image build

Timeline (from server/journal logs, all CDT)

• 20:09:31 — install-minecraft-splitscreen.sh downloaded and run. Completed successfully: Java 25 (jdk-25.0.4.1+1), evsieve binary, PolyMC.AppImage, 4 instances, Steam shortcut integration (backup at 20:12:07) all present on disk afterward.
• 20:15:19-20:15:20 — First launch attempt. steam[10442] chdir's into the PolyMC dir; kernel creates MCSS-slot1/MCSS-slot2 virtual input devices (correct — the two available paired controllers, per splitscreen_state.json's phys_uniq fields).
• 20:16:06 — First systemd-coredump fires.
• 20:16:40 through 20:17:19 — Sustained crash loop: mangoapp (PID varies, under gamescope-session-plus@ogui-steam.service) aborts (SIGABRT, core dumped) and is respawned by gamescope-session-plus roughly once per second — 50+ cycles in ~40 seconds (gamescope-session-plus[15898]: .../gamescope-session-plus: line 325: <pid> Aborted (core dumped) mangoapp). Concurrently, several KDE session helpers crash-loop with rising restart counters: plasma-polkit-agent.service (SIGABRT x4+), plasma-foreground-booster.service ("Failed with result 'core-dump'"), plasma-gmenudbusmenuproxy.service, plasma-kaccess.service, plasma-kded6.service.
• 20:16:55-20:16:56 — Second launch attempt (retry), right in the middle of the ongoing crash storm. Same MCSS-slot1/MCSS-slot2 device creation, same outcome.
• No further attempts logged for the rest of the night.

What's ruled out

• Not a stale-lock issue: orchestrator.sh's flock -w ... 9>"$lock_file" releases automatically when the holding process dies; the leftover splitscreen_state.json.lock on disk this morning is cosmetic, not a blocker.
• Not a kernel/GPU-level fault: no amdgpu/DRM reset, timeout, or hang messages in journalctl -k for the crash window.
• Not OOM: no OOM-killer activity in kernel or userspace logs for this window.
• Not caused by the same evening's reboot cycle: that cycle (5 reboots 17:38-21:02, via bazzite-updater) did not change the OS deployment version — both before and after, rpm-ostree status shows 44.20260921. So whatever triggers this bug was already present before that reboot cycle, not introduced by it.

Leads for further digging

• plasma-foreground-booster involves kcgroups-dmemcg's foreground_booster module, and uresourced was actively reassigning cgroup resources (Setting resources on user-0.slice ...) in the same window — the crash-loop is concentrated around the cgroup/resource-management stack reacting to the splitscreen script's rapid nested-session spawning, not a single isolated app bug. Worth checking whether spawning N nested Plasma/gamescope sessions in quick succession (per this repo's per-player nested-session design) is what's overwhelming/confusing that stack.
• Haven't yet pulled a symbol-resolved backtrace of mangoapp's actual crashing thread (only worker threads sampled so far) — coredumps are on disk at /var/lib/systemd/coredump/core.mangoapp.* on the box if someone wants to dig further with debug symbols.
• Regression context is soft: reported working ~1-2 months ago, but only the last 2 rpm-ostree deployments are retained locally (both from mid-September), so the exact prior-working package versions couldn't be diffed directly.

Repro

2-controller docked-mode launch on this specific hardware (Framework Desktop, not Deck) via the Steam shortcut created by the installer.

[aradanmn]

Root cause found: unhandled C++ exception in mangohud's GPU metrics thread

Pulled a demangled backtrace from one of the ~50 mangoapp coredumps (PID 19941, but consistent across the ones sampled):

AMDGPU::metrics_polling_thread()
  → GPU_fdinfo::find_fd()
  → ghc::filesystem::directory_iterator::directory_iterator(path const&)   [throws]
  → __cxa_throw → std::terminate() → __cxxabiv1::__terminate()
  → __gnu_cxx::__verbose_terminate_handler() → abort()

mangoapp's background AMD-GPU-metrics polling thread walks /proc/*/fd to find which processes hold GPU device fds (so it can read their fdinfo for utilization stats). GPU_fdinfo::find_fd() constructs a ghc::filesystem::directory_iterator over some PID's /proc/<pid>/fd without a try/catch — if that PID exits between being enumerated and the iterator actually opening the directory (ENOENT), the constructor throws, nothing catches it, and the whole process calls std::terminate().

This is a process-churn race, not a resource/cgroup issue — my "leads for further digging" guess about kcgroups-dmemcg/uresourced was a red herring; those were just other things also visibly reacting to the same burst of process creation/exit. This installer's per-player nested-session launch spawns and tears down a lot of processes in a tight window, which is exactly the kind of churn that hits this fdinfo race in mangohud/terra-mangohud 0.8.4-2.fc44 — and once mangoapp starts dying, gamescope-session-plus just respawns it into the same race immediately (hence the ~50 crash/respawn cycles in 40s), destabilizing the whole session while Minecraft is trying to come up.

This looks like an upstream mangohud bug, not something fixable in this repo directly. Two angles:

1. Workaround here: skip launching mangoapp for the splitscreen Steam shortcut specifically (or set MANGOHUD=0/equivalent for that launch), so the overlay isn't running to hit the race at all during the high-churn startup window.
2. Upstream: worth reporting to flightlessmango/MangoHud with this backtrace — happy to file it if wanted.

Coredumps still on disk under /var/lib/systemd/coredump/core.mangoapp.* if anyone wants to go further (I don't have mangohud's own debug symbols installed, so this is from the binary's own retained symbol table, not a source-line-level trace).

[aradanmn]

Correction on root cause, plus fix — hardware-validated

The root-cause comment above (MangoHud PID-churn race) turned out to be wrong — re-derived from the Framework's journal + coredumpctl directly rather than the churn theory. Actual cause and fix:

Real cause: on Bazzite, /usr/bin/kwin_wayland carries a file capability (cap_sys_nice), which makes the process non-dumpable at exec. mangoapp's GPU-metrics thread then gets EACCES scanning the focused nested kwin's /proc/<pid>/fdinfo, and MangoHud 0.8.4 doesn't catch the resulting ghc::filesystem::filesystem_error — it calls std::terminate(). Every core dump's exception was Permission denied: '/proc/<pid>/fdinfo', not a PID-enumeration race. The proposed MANGOHUD=0-on-shortcut workaround couldn't have worked either way: mangoapp is a per-session process spawned by gamescope-session-plus, not by this project's shortcut, and Steam doesn't apply env-var prefixes for non-Steam shortcuts.

Filed upstream: flightlessmango/MangoHud#2152.

Fix: MCSS_NESTED_KWIN_NNP (default off) runs the nested kwin under setpriv --no-new-privs, refusing the capability grant at exec and keeping it dumpable. Committed as fix(#198) (2b3d0a9 after rebase). Hardware-validated live on this same Framework Desktop 2026-09-27 — confirmed via /proc/<pid>/status (NoNewPrivs=1, CapEff=0) and zero mangoapp coredumps through a full launch+teardown cycle, versus 29+ crashes/minute before.

Also found in the same investigation, unrelated to mangoapp: launchFromPlasma had no Game-Mode guard, so a Desktop-Mode double-click of the shortcut could stop plasma-workspace.target on the real desktop's own systemd session on teardown — that's what actually produced the "KDE helper crash-loop" symptom described above, not mangoapp. Fixed in the same commit (launchFromPlasma now calls mcss_require_gamescope before anything else).

One more bug surfaced live while validating this fix, separate issue: bwrap failed every instance spawn on this Bazzite host with Can't mount on symlink destination /home (Bazzite symlinks /home -> /var/home; the Deck's /home is a real partition, so it never hit this). Filed and fixed as #199.