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.
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.