gnome-shell crashes with a SIGSEGV after opening a scratch window repeatedly

[liquidev]

I'm currently developing a desktop app, and my workflow is like so: modify the source code, compile and run the app. Of course starting the app opens a new window, and in my user.js I have the following lines:

    Tiling.defwinprop({
        wm_class: "netcanv",
        scratch_layer: true,
    });

to always open the window on the scratch layer, as I find that less intrusive. It also allows me to test whether the UI layout works properly at the default resolution the app starts in, but I digress.

The point is, if I open the app a sufficient amount of times, gnome-shell just dies. It does so somewhere in libmozjs-78.so, but unfortunately I don't have debug symbols installed on my system so I can't check where exactly at the moment.

I have concluded that this is caused by PaperWM by disabling all extensions except PaperWM itself, re-running my test, then disabling PaperWM altogether to end up with vanilla GNOME, and running the test again; and indeed this only seems to happen within PaperWM. I also tried this with another program to see whether this is a problem with winit, and this also happens with a GLFW game of mine, so I assume this is not a problem with the windowing library.

This issue is particularly annoying on Wayland, because when gnome-shell crashes on Wayland, it brings down the entire session manager (?) along with it for some reason, which prevents me from logging into another Wayland session again. On X.org the crash is handled a lot more gracefully, as gnome-shell just reopens after the crash happens, which at least allows me to continue working.

Please let me know if anyone else is successful at reproducing this. If not, I can try to compile libmozjs with debug symbols to try and debug the issue further.

• gnome-shell/mutter version: 3.38.4 (using aur/mutter-performance, but vanilla Mutter also has this issue)
• PaperWM commit hash: edcb20d

[chetwisniewski]

I have been experiencing this for at least a month as well. Very annoying and exactly as described by liquidev. In my case it is triggered by "scratch dialogs" like file open dialogs, Zoom meetings and Signal which I all keep in the scratch.

[olejorgenb]

Output from journalctl $(which gnome-shell) around the time of the crash could be helpful for debugging. I'm on 3.38 on one machine now, so maybe it'll happen here also.

[chetwisniewski]

I think this log is the last time it occurred on my Desktop PC with amdgpu.

gnome-shell-crash-wayland.txt

[gosticks]

I am also facing this issue be it on an unsupported version of gnome (41) and nvidia gpu. Since I really love PaperWM and know some JS I would be willing to investigate the issue. Unfortunately I have no idea of gnome so if someone could point me in the right direction that would be appreciated.

[Thesola10]

On my machine, the issue appears to be triggered by windows set to open in the scratch layer by default, not by existing windows sent to scratch nor by modal dialogs.

[Thesola10]

Found and permanently squished the issue on my fork Thesola10/PaperWM

This clone is the culprit, it caused a native race condition even after waiting for first-frame, so I wrapped it in if (fromTiling): https://github.com/paperwm/PaperWM/blob/2f5281940d5b7e8e6c80299784f70b1a7f74ecc6/scratch.js#L68

[Thesola10]

This issue should be fixed in #418

[jtaala]

Closing as issue reportedly fixed by #418. Please comment if others are still having this issue and we can reopen.