PaperWM
PaperWM copied to clipboard
Crash when a window locks and releases the cursor
Describe the bug When a window locks the cursor and later releases it, this causes the cursor to stay locked, or puts it into some sort of illegal state, which then causes gnome-shell to crash.
To Reproduce I've managed to reproduce it most consistently on Wayland with a Rust Bevy app. Here is a reproduction repo: https://github.com/aecsocket/paperwm-crash-repro
cargo run- The window will lock your cursor so you can't move it
- Try alt-tabbing, Win+L/R, etc. Free your cursor, move it to some other apps, try doing some stuff.
- Tab back into the window then Alt+F4
- Your cursor should remain frozen, and if you try to move it, gnome-shell crashes
Expected behavior It shouldn't crash.
Screenshots I would try to attach a video here, but I can't record with OBS since as soon as gnome-shell crashes, all windows are torn down as well, and OBS crashes. If anyone knows how I can record a video of my entire desktop outside of GNOME somehow, please let me know.
System information: Please provide system information:
-
if you installed PaperWM via extensions.gnome.org please open PaperWM settings and select the
Abouttab (last tab) and click theCopy to Clipboardbutton and paste the information below, or; -
if you installed via source code, please execute
./gather-system-info.shin you PaperWM clone and paste the information below
Distribution: Bazzite 40.20240908.0 (Silverblue)
GNOME Shell: 46.4
Display server: Wayland
PaperWM version: 46.17.1
Enabled extensions:
- [email protected]
Additional context I'm not sure how to debug this issue properly, since it probably involves some interaction between PaperWM and gnome-shell, and probably isn't solely PaperWM's fault.
I haven't managed to reproduce this with 0 extensions running.
What I have managed to piece together is:
- I have a coredump of gnome-shell as it crashes, which points towards a function in mutter
- it's related to mutter's
meta_wayland_pointer_constraint_deactivate()function- https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/wayland/meta-wayland-pointer-constraints.c#L566
- The crash is the same one as in this issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/3416
Core dump stack trace:
Stack trace of thread 22274:
#0 0x00007f6632ea8664 __pthread_kill_implementation (libc.so.6 + 0x99664)
#1 0x00007f6632e4fc4e raise (libc.so.6 + 0x40c4e)
#2 0x000055ab76859ba6 dump_gjs_stack_on_signal_handler (gnome-shell + 0x4ba6)
#3 0x00007f6632e4fd00 __restore_rt (libc.so.6 + 0x40d00)
#4 0x00007f6632ea8664 __pthread_kill_implementation (libc.so.6 + 0x99664)
#5 0x00007f6632e4fc4e raise (libc.so.6 + 0x40c4e)
#6 0x00007f6632e37902 abort (libc.so.6 + 0x28902)
#7 0x00007f6633ad210c g_assertion_message.cold (libglib-2.0.so.0 + 0x2010c)
#8 0x00007f6633b3f397 g_assertion_message_expr (libglib-2.0.so.0 + 0x8d397)
#9 0x00007f663315878c meta_wayland_pointer_constraint_deactivate (libmutter-14.so.0 + 0x15878c)
#10 0x00007f66330cf3af event_callback.lto_priv.0 (libmutter-14.so.0 + 0xcf3af)
#11 0x00007f6633387d5b _clutter_event_process_filters (libmutter-clutter-14.so.0 + 0x5dd5b)
#12 0x00007f66333bef8d clutter_stage_notify_grab_on_pointer_entry (libmutter-clutter-14.so.0 + 0x94f8d)
#13 0x00007f66333bf472 clutter_stage_notify_grab (libmutter-clutter-14.so.0 + 0x95472)
#14 0x00007f66333bfd41 clutter_stage_unlink_grab (libmutter-clutter-14.so.0 + 0x95d41)
#15 0x00007f66324e6056 ffi_call_unix64 (libffi.so.8 + 0x9056)
#16 0x00007f66324e26a0 ffi_call_int.lto_priv.0 (libffi.so.8 + 0x56a0)
#17 0x00007f66324e54ee ffi_call (libffi.so.8 + 0x84ee)
#18 0x00007f663348008e _ZN3Gjs8Function6invokeEP9JSContextRKN2JS8CallArgsENS3_6HandleIP8JSObjectEEP11_GIArgument.localalias.lto_priv.0 (l>
#19 0x00007f66334814b3 _ZN3Gjs8Function4callEP9JSContextjPN2JS5ValueE (libgjs.so.0 + 0x564b3)
#20 0x00007f663167d044 _ZN2js23InternalCallOrConstructEP9JSContextRKN2JS8CallArgsENS_14MaybeConstructENS_10CallReasonE (libmozjs-115.so.0>
#21 0x00007f6631686966 _ZN2js9InterpretEP9JSContextRNS_8RunStateE (libmozjs-115.so.0 + 0x86966)
#22 0x00007f663167ca5b _ZN2js9RunScriptEP9JSContextRNS_8RunStateE (libmozjs-115.so.0 + 0x7ca5b)
#23 0x00007f663167cf47 _ZN2js23InternalCallOrConstructEP9JSContextRKN2JS8CallArgsENS_14MaybeConstructENS_10CallReasonE (libmozjs-115.so.0>
#24 0x00007f663167d3bd _ZN2js4CallEP9JSContextN2JS6HandleINS2_5ValueEEES5_RKNS_13AnyInvokeArgsENS2_13MutableHandleIS4_EENS_10CallReasonE >
#25 0x00007f6631703391 _Z20JS_CallFunctionValueP9JSContextN2JS6HandleIP8JSObjectEENS2_INS1_5ValueEEERKNS1_16HandleValueArrayENS1_13Mutabl>
#26 0x00007f6633474dc5 _ZN3Gjs7Closure6invokeEN2JS6HandleIP8JSObjectEERKNS1_16HandleValueArrayENS1_13MutableHandleINS1_5ValueEEE (libgjs.>
#27 0x00007f66334b1434 _ZN3Gjs7Closure7marshalEP7_GValuejPKS1_PvS5_ (libgjs.so.0 + 0x86434)
#28 0x00007f66335e364a g_closure_invoke (libgobject-2.0.so.0 + 0x1164a)
#29 0x00007f66336135f3 signal_emit_unlocked_R.isra.0 (libgobject-2.0.so.0 + 0x415f3)
#30 0x00007f6633604104 signal_emit_valist_unlocked (libgobject-2.0.so.0 + 0x32104)
#31 0x00007f6633604361 g_signal_emit_valist (libgobject-2.0.so.0 + 0x32361)
#32 0x00007f6633604423 g_signal_emit (libgobject-2.0.so.0 + 0x32423)
#33 0x00007f66333cb592 clutter_text_activate (libmutter-clutter-14.so.0 + 0xa1592)
#34 0x00007f663335adfd _clutter_marshal_BOOLEAN__STRING_UINT_FLAGS (libmutter-clutter-14.so.0 + 0x30dfd)
#35 0x00007f66335e364a g_closure_invoke (libgobject-2.0.so.0 + 0x1164a)
#36 0x00007f66333810b5 clutter_binding_pool_activate (libmutter-clutter-14.so.0 + 0x570b5)
#37 0x00007f66333c2c03 clutter_text_key_press (libmutter-clutter-14.so.0 + 0x98c03)
#38 0x00007f663335b300 _clutter_marshal_BOOLEAN__BOXED.part.0 (libmutter-clutter-14.so.0 + 0x31300)
#39 0x00007f66335e364a g_closure_invoke (libgobject-2.0.so.0 + 0x1164a)
#40 0x00007f6633613bd0 signal_emit_unlocked_R.isra.0 (libgobject-2.0.so.0 + 0x41bd0)
#41 0x00007f6633603969 signal_emit_valist_unlocked (libgobject-2.0.so.0 + 0x31969)
#42 0x00007f6633604361 g_signal_emit_valist (libgobject-2.0.so.0 + 0x32361)
#43 0x00007f6633604423 g_signal_emit (libgobject-2.0.so.0 + 0x32423)
... and more
There's probably some more useful info that I can give eg GJS logs, or some other stack trace or logs, but I'm not sure what I'm looking for since I'm not experienced with debugging GNOME. If there's any other info I can give that's helpful to debug please let me know.
Also, if you know how I can record a video of this even though gnome-shell and OBS crashes, please let me know.
Also, if you know how I can record a video of this even though gnome-shell and OBS crashes, please let me know.
The only way to record a video that I can think of is either running it in a VM or a nested shell and recording that from the outside.
As for logs, you could try checking the logs of gnome-shell when it crashed in journalctl.
I also tried to reproduce it, but I couldn't get it to crash.
The only thing I noticed in the logs was that this was printed a bunch of times after quitting (not sure if it means anything):
Sep 09 21:09:14 anarchy gnome-shell[2191]: (../mutter/src/wayland/meta-wayland-pointer-constraints.c:478):should_constraint_be_enabled: runtime check failed: (meta_wayland_surface_is_xwayland (constraint->surface) || META_IS_WAYLAND_SUBSURFACE (constraint->surface->role))
I'm also on Gnome 46.4 wayland, but I'm on Arch. If it matters: I am using two monitors.
Hey all, like @Lythenas mentioned, I can't reproduce this, let me know if I'm doing anything wrong:
Screencast from 2024-09-10 07-50-38.webm
Closing the window (with alt+f4):
Screencast from 2024-09-10 08-00-27.webm
I'm moving my mouse lots while the window is selected.
I suspect this relates to the video driver/card you're using. I note that cargo run wouldn't compile with I was running Integrated (I have a Nvidia / prime laptop). Once switching to Hybrid it would compile fine.
Not seeing any crash, but like @Lythenas, am seeing that error output in logs.
I feel like that meta-wayland-pointer-constraints is very closely related to the error that's happening here, since I get the same error message before the assertion fails and gnome-shell crashes. I can see this in journalctl right before the assertion fails and systemd-coredump prints the core dump info.
After a lot of trial and error, I have managed to reproduce the crash 2 more times, both times on Bazzite. In total, I can reproduce this on:
- my laptop, Framework 13, with integrated graphics
- my desktop, with a dedicated GPU
- a QEMU virtual machine using virt-manager, with lavapipe software renderer
Video of the crash in a VM - you can see that I disabled all other gnome-shell extensions, and my mouse cursor disappears when I hover inside the VM after the crash, then it black screens. On my real machine, this kicks me back to the gdm login screen, but seems to crash even harder in the VM.
https://github.com/user-attachments/assets/be8a2772-582a-4e1d-ab7f-353d27426a58
Video of the same VM without PaperWM enabled:
https://github.com/user-attachments/assets/1e81e091-631c-4db8-b35b-6a356b9235ce
Reproduction steps:
- Download a Bazzite ISO image, make a QEMU VM with it, and install it
- Disable all extensions and install PaperWM
- Set up lavapipe (Vulkan software renderer) inside the VM so that the Bevy app can find a GPU
sudo tee /etc/vulkan/icd.d/lvp_icd.x86_64.json > /dev/null << EOL
{
"ICD": {
"library_path": "libvulkan_lvp.so",
"api_version": "1.3.204"
},
"file_format_version": "1.0.0"
}
EOL
- Check that
vulkaninfogives you some output on this lavapipe GPU, and doesn't error - Download and run the sample Bevy app
distrobox create --image archlinux:latest --name dev
distrobox enter dev
sudo pacman -S base-devel git rustup alsa-lib
git clone https://github.com/aecsocket/paperwm-crash-repro
cd paperwm-crash-repro
rustup default stable
cargo run
- Follow the same steps as in the original issue
Note that I could not reproduce the crash on a fresh image of Fedora Workstation 40 in a VM, on gnome-shell 46.0 (not 46.4).
Distribution: Fedora Linux 40 (Workstation Edition)
GNOME Shell: 46.0
Display server: Wayland
PaperWM version: 46.17.1
Enabled extensions:
- [email protected]
- [email protected]
This clearly points to Bazzite being the source of the issue here, but I'm confused on what kind of interaction Bazzite, PaperWM and gnome-shell could be having to cause this crash. I suppose the next step is to investigate what kind of changes Bazzite is making to GNOME, and see if one of those conflicts with what PaperWM is doing somehow? Although I feel like I'm starting to go out of my depth here.
This clearly points to Bazzite being the source of the issue here
Bazzite dev here, replying to say I ran your example commands on a GNOME build with the only enabled extension being PaperWM and could not reproduce the crash.
Our GNOME is patched only with Ubuntu's triple buffering MR, and a ~6 line patch for changing Switcheroo's behavior when selecting the "alternative" GPU.
It may not be a patch but something else that Bazzite does that causes this. But I can definitely reproduce it in a VM - here is another video of the crash.
https://github.com/user-attachments/assets/754ac942-3078-4952-884d-b1431210412b
(Note that I fail to get the crash on the first attempt, and the app closes fine. On the second attempt it does crash.)
The host in this video is my desktop, with a nearly out-of-the-box Bazzite install running on bare metal (I only set up sunshine + moonlight so that I can play games on it from my laptop, and setup virtualization to run the VM). I've created another VM and installed Bazzite on it, then followed the same steps I outlined above. I ran ujust update to fully update the system before doing this test, so I can't see the problem being anything other than some sort of weird interaction between Bazzite/gnome-shell/PaperWM. It's also possible that I have some sort of weird hardware issue on both of my machines (and I definitely have had cursed issues before to do with my hardware), but I don't think that's likely.
This clearly points to Bazzite being the source of the issue here
Bazzite dev here, replying to say I ran your example commands on a GNOME build with the only enabled extension being PaperWM and could not reproduce the crash.
Our GNOME is patched only with Ubuntu's triple buffering MR, and a ~6 line patch for changing Switcheroo's behavior when selecting the "alternative" GPU.
Is it possible that you have some sort of extra settings changed related to GNOME which fixes this issue? The video above is from the stock Bazzite ISO - I selected "Virtual Machine" -> "AMD" -> "GNOME", and I downloaded that ISO today specifically to test this issue, so maybe you have some different configuration which causes this issue to not happen.
After updating to Fedora 41, GNOME 47 and latest PaperWM I can't reproduce this issue anymore. It was probably some sort of weird coincidence where everything lined up in just the wrong way to trigger a crash.
Update: I reproduced the issue again literally the day after closing this issue, but I'm not using PaperWM anymore, so I can't confirm if this issue is resolved or not. I love the extension and the entire scrolling horizontal workspace concept, it really is so much better than tiling or stacking; but this crash makes the extension unusable for my work, so unfortunately I can't use it. I'm leaving this issue closed.