-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
warp_to_constraint_cursor_hint: Handle NULL view #7349
Conversation
This might be the wrong fix, but the crash is happening because the ->data field on an xwayland surface is NULL. A NULL data field is normal for unmanaged surfaces, however it seems clients can do weird things: They can create a cursor lock on a regular xwayland surface then make it unmanaged by calling override_redirect. In this case, the xwayland server should destroy the cursor lock, which is does, but does so in the wrong order making it try to dereference a NULL pointer after sway has acknowledged its new unmanaged status. ``` (gdb) bt full 0 0x000055fd91934861 in warp_to_constraint_cursor_hint (cursor=0x55fd93486c00) at ../sway/input/cursor.c:1243 sy = 605 lx = 6.9527431433545762e-310 sx = 1272 view = 0x0 con = 0x7ffd1cdfe400 ly = -6.949595189996421e+59 constraint = 0x55fd93e7faa0 1 0x000055fd91934976 in handle_constraint_destroy (listener=0x55fd93f0fd58, data=0x55fd93e7faa0) at ../sway/input/cursor.c:1266 sway_constraint = 0x55fd93f0fd30 constraint = 0x55fd93e7faa0 cursor = 0x55fd93486c00 2 0x00007fda8275bf6e in wl_signal_emit_mutable () at /usr/lib/libwayland-server.so.0 3 0x00007fda82e57016 in pointer_constraint_destroy (constraint=0x55fd93e7faa0) at ../subprojects/wlroots/types/wlr_pointer_constraints_v1.c:49 4 0x00007fda82e570dc in pointer_constraint_destroy_resource (resource=0x55fd933cf8f0) at ../subprojects/wlroots/types/wlr_pointer_constraints_v1.c:66 constraint = 0x55fd93e7faa0 5 0x00007fda8275d8ba in () at /usr/lib/libwayland-server.so.0 6 0x00007fda8275f6a9 in wl_resource_destroy () at /usr/lib/libwayland-server.so.0 7 0x00007fda82e56fb3 in resource_destroy (client=0x55fd93ea52e0, resource=0x55fd933cf8f0) at ../subprojects/wlroots/types/wlr_pointer_constraints_v1.c:39 8 0x00007fda81d8f4f6 in () at /usr/lib/libffi.so.8 9 0x00007fda81d8bf5e in () at /usr/lib/libffi.so.8 10 0x00007fda81d8eb73 in ffi_call () at /usr/lib/libffi.so.8 11 0x00007fda8275aada in () at /usr/lib/libwayland-server.so.0 12 0x00007fda8275f01c in () at /usr/lib/libwayland-server.so.0 13 0x00007fda8275d9e2 in wl_event_loop_dispatch () at /usr/lib/libwayland-server.so.0 14 0x00007fda8275e197 in wl_display_run () at /usr/lib/libwayland-server.so.0 15 0x000055fd919264d3 in server_run (server=0x55fd919a3a80 <server>) at ../sway/server.c:320 16 0x000055fd91925457 in main (argc=1, argv=0x7ffd1cdfed98) at ../sway/main.c:411 verbose = false debug = false validate = false allow_unsupported_gpu = false config_path = 0x0 c = -1 ```
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Xwayland doesn't care about managed/unmanaged.
That said, maybe the client switches from managed to unmanaged and ends the lock at the same time. Since there is no synchronization between the X11 and Wayland sockets, there is no ordering guarantee between these two events.
Sounds like something we need to handle.
Thanks! |
This seems related: Okay, digging deeper, there seems to be a bug at line 1325 of the latest sway's cursor.c I am able to reproduce a crash and coredump in sway any time I choose a beat subdivision timing within Bitwig-Studio. The selection process involves a mouse click to pull up the options mini-panel, and then holding the mouse button down while dragging to select the subdivision of a beat timing I desire ( triole, quintole, septole, etc...). Crash and coredump and abrupt end of login session every time. from coredump analysis: Core was generated by `sway'. #0 0x000055862c09defb in warp_to_constraint_cursor_hint (cursor=cursor@entry=0x55862d9495e0) at ../sway-1.8/sway/input/cursor.c:1325 |
a full backtrace:
#10 0x00007f60076a201c in wl_client_connection_data (fd=, mask=, data=) at ../wayland-1.21.0/src/wayland-server.c:437
= 1475591424, data = {ptr = 0x23d2ec98, fd = 601025688, u32 = 601025688, u64 = 601025688}}, {events = 0, data = {ptr = 0x55862c08dab0 <execute_command+816>, fd = 738777776, u32 = 738777776, u64 = 94034752756400}}, {events = 739127459, data = {ptr = 0x13700005586, fd = 21894, u32 = 21894, u64 = 1335734850950}}, {events = 0, data = {ptr = 0x55862d8972d0, fd = 763982544, u32 = 763982544, u64 = 94034777961168}}, {events = 805713092, data = {ptr = 0x2d947ab000000000, fd = 0, u32 = 0, u64 = 3284384924592766976}}, {events = 21894, data = {ptr = 0x0, fd = 0, u32 = 0, u64 = 0}}, {events = 124371216, data = {ptr = 0x2d96af0000000000, fd = 0, u32 = 0, u64 = 3285005392748216320}}, {events = 21894, data = {ptr = 0x55862d947160, fd = 764703072, u32 = 764703072, u64 = 94034778681696}}, {events = 1475591424, data = {ptr = 0x23d2ec98, fd = 601025688, u32 = 601025688, u64 = 601025688}}, {events = 0, data = {ptr = 0x55862e236870, fd = 774072432, u32 = 774072432, u64 = 94034788051056}}} |
This patch is supposed to fix that crash? The line numbers are different because I run sway with a bunch of patches on top. |
This might be the wrong fix, but the crash is happening because the ->data field on an xwayland surface is NULL. A NULL data field is normal for unmanaged surfaces, however it seems clients can do weird things: They can create a cursor lock on a regular xwayland surface then make it unmanaged by calling override_redirect. In this case, the xwayland server should destroy the cursor lock, which is does, but does so in the wrong order making it try to dereference a NULL pointer after sway has acknowledged its new unmanaged status.