For a few months, I got used to my laptop randomly crashing and dropping me back to the login screen two or three times a day. This was common, and I had incorporated it into my work schedule. The day that finally broke the camel’s back was when my system crashed in the middle of a coding session, while I was working on a time-sensitive feature for a hackathon that I had joined (and won; my teammates and I came in first place). The desktop session abruptly ending meant that all the open apps were terminated, thus interrupting my workflow.
I decided to finally fix it by troubleshooting what the root cause was. This took me down a rabbit hole, but I was able to pinpoint the culprit: the GNOME Shell extension, Quick Settings Tweaks by qwreey. This is an extension that helps users add Media Controls, Notifications, and Volume Mixer to the quick settings. I had this extension installed on Ubuntu 24.04.4, running GNOME 46 with Wayland.
My investigation began by getting the system logs and working backwards to see what is happening exactly before the session terminates abruptly and the system returns to the GDM login screen as if the user had logged out. To get the logs generated by the systemd-journald service, I used the journalctl command and dumped the result to a text file appropriately named “crashreport.txt”
journalctl -b 0 --no-pager > crashreport.txt
Since the computer never rebooted, the logs I needed were in the current boot, hence journalctl -b 0. If we needed the previous boot, we would use journalctl -b -1. The --no-pager is to instruct journalctl to output as a single stream and not use an interactive tool like less, which would force me to scroll manually.
The first thing after opening the log file was to navigate to the time the crash happened and check the activity right before systemd started shutting down services. What stood out was that the kernel logged a segmentation fault in the gnome shell process:
kernel: gnome-shell[5937]: segfault at 0 ip 00007468b779ad6d sp 00007fff1821cff0 error 4 in libgjs.so.0.0.0[31d6d,7468b7789000+a6000] likely on CPU 6 (core 3, socket 0)
In simpler terms, the system kernel recorded a user-mode read violation error (error 4) caused by GNOME Shell running under process ID 5937 due to a segmentation fault (segfault at 0). At “0” means GNOME Shell tried to read/write to a null memory address, which is the classic signature of dereferencing a NULL pointer. The faulting instructions are in the file libgjs, the shared engine that executes both the Shell’s own JavaScript and every installed extension.
Everything else that followed in the journal was a consequence of that one process dying.
Although descriptive, this was still not enough to pinpoint which shell extension was responsible for the crash. Due to my naivety, I was quick to blame the first shell extension app closest to the crash, which was clipboard-history with 253 instances of lines like:
gnome-shell[5937]: Object St.Button (0x5956b5afe0e0), has been already disposed — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
To be fair, other extensions were erroring out with a similar message. There were hundreds from different installed extensions. My next step was to scroll through them all and find the one that started it. This meant searching through the whole boot and not just the crash window. Counting extension names in the stack frames gave me this:
Each incident logged the same pair of lines: an “already disposed” error on an St.Button, then a GObject complaint that the instance “has no handler” for a signal ID, meaning something tried to disconnect a signal from a widget that no longer existed.
All four occurrences carried an identical stack trace (home path anonymised for obvious reasons):
Read bottom to top: the Shell’s extension system calls the extension, which calls a cleanup helper, which touches a widget that is already gone. The extensionSystem.js frames suggest this was the extension’s enable/disable lifecycle code, not user interaction.
After deep analysis, I narrowed it down to the extension Quick Settings Tweaks as the genesis of the crashes. My working explanation is that several extensions place widgets in the same top-bar and Quick Settings area. If one extension destroys a shared container or widget twice, or disconnects signals from objects that are already gone, other extensions holding references into that area start touching freed objects. Three times the damage stayed small. The fourth time it spread, and a NULL dereference inside GJS ended the process.
Why the shell crash felt like a logout is because in Wayland, there is no separate window manager and display server to fail independently. GNOME Shell is the compositor, so its death takes every client connection with it. GDM notices that the session’s compositor is gone, closes the session, and starts a new greeter. To the user, the sequence is indistinguishable from logging out, except that unsaved work is lost.
To remediate the situation, I uninstalled the extension. The crash never happened again, which confirmed it as the cause. I have since upgraded from Ubuntu 24.04 (GNOME 46) to Ubuntu 26.04 (GNOME 50), and the desktop has stayed stable. The removal test shows who caused the crash, not how. I never examined a core dump, so that part stays a hypothesis.The removal test shows who caused the crash, not how. I never examined a core dump, so that part stays a hypothesis.
I tried to report the issue to the extension author, but it seems the project has been abandoned and is no longer maintained. For everyone who still needs the features, you can try Quick Settings Tweaks v2.2-offx1.1. It is a fork of the original project but is maintained and supports the latest GNOME Shell versions.
Top comments (1)
Really insiteful 🔥