Update: managed to catch the freeze live and get a real backtrace, which changes the diagnosis significantly — this is not a GPU/DRM/Mutter- rendering issue, it's gnome-shell's own JS main thread hanging
What I did Installed openssh-server on the machine. The next time it froze, I SSHed in from a phone on the same LAN while the display and input were still completely dead. The SSH connection worked immediately — confirming the machine itself (kernel, networking) was fully alive the whole time; only the graphical session was frozen. Before doing anything else, I also checked top from that SSH session: exactly one CPU core was pinned at 100% by the gnome-shell process for the entire duration of the freeze. That rules out a deadlock/blocked-syscall explanation — the main thread wasn't waiting on anything, it was actively spinning. From the same SSH session I attached gdb to the running gnome-shell process and captured a full all-threads backtrace: sudo gdb -p $(pidof gnome-shell) -batch -ex "thread apply all bt" -ex detach Result (50 threads total) Thread 1, "gnome-shell" (the main thread), is stuck entirely inside libmozjs-140.so (SpiderMonkey, the JS engine GJS uses to run gnome-shell's own UI code and all shell extensions). The top frames are unresolved (??) JIT-compiled JS frames with no native symbols — consistent with an infinite loop or a wedged call somewhere in JS execution, not a crash or a wait. Zero frames anywhere in the entire 50-thread dump mention drm, i915, ioctl, egl, gbm, cogl, or clutter. The GPU/rendering path was never reached during the hang. The "KMS thread" and "Mutter Input Th" (both in libmutter-51.so.0) are perfectly healthy — both sitting idle in g_main_loop_run() → ppoll(), waiting normally for events. They're not blocked on anything; they're just never getting serviced because the main thread never returns to the loop. Why this matters This points specifically at a hang inside GJS/SpiderMonkey execution on gnome-shell's main thread, not a graphics driver, DRM/KMS, or Mutter rendering-path bug as I originally suspected. Since gnome-shell's core UI (js/ui/*.js) and every enabled extension run on this same JS engine and thread, I can't yet tell from this alone whether it's core shell JS or one of the extensions that were still enabled at capture time (appindicatorsupport, clipboard-indicator, Vitals, Bluetooth-Battery- Meter, tiling-assistant, ubuntu-dock — every other extension had already been ruled out and disabled/removed by this point in my testing). Getting mozjs-140/gjs debug symbols installed and recapturing would likely resolve the ?? frames into real function names and narrow this further — I'm happy to do that if it would help. I have the full 50-thread backtrace saved and have attached it. ** Attachment added: "gnome-shell-freeze-backtrace.txt" https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2167843/+attachment/6001504/+files/gnome-shell-freeze-backtrace.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2167843 Title: Since upgrading to 26.10, the system freezes completely and unrecoverably within 1-6 minutes of starting a GNOME (Wayland) graphical session. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2167843/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
