SIGSEGV in wlr_subsurface_create

[nagisa]

I use sway. Launched mpv and had sway crash with the stack trace like this:

#0  0x00007fc40345f1c3 in wl_list_insert () at /usr/lib/libwayland-server.so.0
#1  0x00007fc4034167f9 in wlr_signal_emit_safe (signal=signal@entry=0x5645d6cfc5c0, data=data@entry=0x5645d6d6b620) at ../util/signal.c:19
#2  0x00007fc403412909 in wlr_subsurface_create (surface=0x5645d6d80ff0, parent=0x5645d6cfc310, version=1, id=178, resource_list=0x5645d68df018) at ../types/wlr_surface.c:980
#3  0x00007fc4027e86d0 in ffi_call_unix64 () at /usr/lib/libffi.so.6
#4  0x00007fc4027e80a0 in ffi_call () at /usr/lib/libffi.so.6
#5  0x00007fc40345e82f in  () at /usr/lib/libwayland-server.so.0
#6  0x00007fc40345b193 in  () at /usr/lib/libwayland-server.so.0
#7  0x00007fc40345c7f2 in wl_event_loop_dispatch () at /usr/lib/libwayland-server.so.0
#8  0x00007fc40345b39c in wl_display_run () at /usr/lib/libwayland-server.so.0
#9  0x00005645d6363612 in main (argc=1, argv=0x7ffd0465fa78) at ../sway/sway/main.c:402

This failed on the 2nd wl_list_insert call within wlr_signal_emit_safe:

Dump of assembler code for function wlr_signal_emit_safe:
   0x00007fc4034167c0 <+0>:	push   %r14
   0x00007fc4034167c2 <+2>:	lea    -0x19(%rip),%r14        # 0x7fc4034167b0 <handle_noop>
   0x00007fc4034167c9 <+9>:	push   %r13
   0x00007fc4034167cb <+11>:	mov    %rsi,%r13
   0x00007fc4034167ce <+14>:	push   %r12
   0x00007fc4034167d0 <+16>:	push   %rbp
   0x00007fc4034167d1 <+17>:	push   %rbx
   0x00007fc4034167d2 <+18>:	mov    %rdi,%rbx
   0x00007fc4034167d5 <+21>:	sub    $0x40,%rsp
   0x00007fc4034167d9 <+25>:	mov    %rsp,%rbp
   0x00007fc4034167dc <+28>:	lea    0x20(%rsp),%r12
   0x00007fc4034167e1 <+33>:	mov    %rbp,%rsi
   0x00007fc4034167e4 <+36>:	callq  0x7fc4033c5f50 <wl_list_insert@plt>
   0x00007fc4034167e9 <+41>:	mov    (%rbx),%rdi
   0x00007fc4034167ec <+44>:	mov    %r12,%rsi
   0x00007fc4034167ef <+47>:	mov    %r14,0x10(%rsp)
   0x00007fc4034167f4 <+52>:	callq  0x7fc4033c5f50 <wl_list_insert@plt>
=> 0x00007fc4034167f9 <+57>:	mov    0x8(%rsp),%rbx
   0x00007fc4034167fe <+62>:	mov    %r14,0x30(%rsp)
   0x00007fc403416803 <+67>:	cmp    %r12,%rbx
...

with locals like these:

cursor = {link = {prev = 0x5645d6cfc5c0, next = 0x5645d6d8ff10}, notify = 0x7fc4034167b0 <handle_noop>}
end = {link = {prev = 0x5645d6d8ff10, next = 0x101000000000002}, notify = 0x5645d6909740}

The fault address is the end.link.next = 0x101000000000002.

Reporting here instead of against sway as there appear to be no sway-related frames in the faulting stacktrace.

wlroots built from git on october 10th.

---

wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1856

[ammen99]

Can you recompile Sway with Address Sanitizer and check the backtrace it gives? Sometimes memory corruption can give such backtraces which don't point to the real problem.

[nagisa]

This is a super rare issue; I doubt I’ll be able to reproduce it again.