Sway 1.8-dev crash on window close

[hissssst]

• Sway Version:
  sway version 1.8-dev

• Debug Log:
  sway2.log

• Configuration File:
  https://0x0.st/ok-4.txt

• Stack Trace:
  No stack trace, just (core dumped) exited with code 1

• Description:
  This bug rarely happens, but when I close firefox window (Mozilla Firefox 102.5.0esr), sway crashes

[bl4ckb0ne]

11:36:33.556 [DEBUG] [wlr] [backend/drm/renderer.c:315] Failed to get DMA-BUF from buffer
11:36:33.556 [DEBUG] [wlr] [backend/drm/drm.c:423] connector eDP-1: Failed to import buffer for scan-out

Strange.

Do you run firefox with the wayland backend?

[hissssst]

Do you run firefox with the wayland backend?

Yes

[bl4ckb0ne]

Are you able to provide a stacktrace?

[hissssst]

Are you able to provide a stacktrace?

How? The process just finishes up without any stacktrace and shell shows (core dumped) exited with code 1

[bl4ckb0ne]

I don't know what distro you're using, coredumpctl, gdb trace, anything that can point to a problem in the code. We can't do much with a "that bug rarely happens" and a sway log that has no significant error.

[hissssst]

sway.coredump.txt

Here you go

UPD: I can't open this file in github, here's the link: https://0x0.st/oku0.txt

[hissssst]

But I think this is a coredump from a latest crash. However, it is caused by the same actions (closing firefox)

[hissssst]

@emersion , what does "waiting on reporter" label mean? Do I need to provide more information?

[bl4ckb0ne]

                #0  0x0000000000456336 container_get_siblings (sway + 0x56336)
                #1  0x000000000041791a get_deco_rect.constprop.0 (sway + 0x1791a)
                #2  0x0000000000418e80 ipc_json_describe_node (sway + 0x18e80)
                #3  0x00000000004180e6 ipc_json_describe_node_recursive (sway + 0x180e6)
                #4  0x000000000041b4e2 ipc_event_window (sway + 0x1b4e2)
                #5  0x0000000000456588 container_begin_destroy (sway + 0x56588)
                #6  0x0000000000459e82 view_unmap (sway + 0x59e82)
                #7  0x0000000000426f5c handle_unmap (sway + 0x26f5c)
                #8  0x00007f28c6a7290c wl_signal_emit_mutable (libwayland-server.so.0 + 0x990c)
                #9  0x00007f28c69f3482 unmap_xdg_surface (libwlroots.so.11 + 0x6d482)
                #10 0x00007f28c69f3885 reset_xdg_surface (libwlroots.so.11 + 0x6d885)
                #11 0x00007f28c6a70ee7 destroy_resource (libwayland-server.so.0 + 0x7ee7)
                #12 0x00007f28c6a715f0 wl_resource_destroy (libwayland-server.so.0 + 0x85f0)
                #13 0x00007f28c601a8aa ffi_call_unix64 (libffi.so.8 + 0x78aa)
                #14 0x00007f28c60198bb ffi_call_int (libffi.so.8 + 0x68bb)
                #15 0x00007f28c601a33e ffi_call (libffi.so.8 + 0x733e)
                #16 0x00007f28c6a76961 wl_closure_invoke (libwayland-server.so.0 + 0xd961)
                #17 0x00007f28c6a71bda wl_client_connection_data (libwayland-server.so.0 + 0x8bda)
                #18 0x00007f28c6a7488a wl_event_loop_dispatch (libwayland-server.so.0 + 0xb88a)
                #19 0x00007f28c6a72365 wl_display_run (libwayland-server.so.0 + 0x9365)
                #20 0x0000000000411f18 main (sway + 0x11f18)
                #21 0x00007f28c671a24e __libc_start_call_main (libc.so.6 + 0x2924e)
                #22 0x00007f28c671a309 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x29309)
                #23 0x00000000004120f5 _start (sway + 0x120f5)

Looks like a bug indeed. Did you find a way to reproduce it deterministically? What are the condition to make it crash, is firefox the only window on the screen?

[hissssst]

@bl4ckb0ne I've found a way to reproduce it

1. Open any window
2. Move it to scratchpad
3. Hide it
4. Kill the window process

[bl4ckb0ne]

Can you try #7315 ?

[hissssst]

Maybe next week. If you were able to reproduce the issue and this commit fixes it, just close it

[bl4ckb0ne]

@hissssst i made some changes to the patch. If you could test it, it would be greatly appreciated.

[emersion]

Can you confirm this is fixed in master?

[Zeioth]

I just tested master and I got the same

11:36:33.556 [DEBUG] [wlr] [backend/drm/renderer.c:315] Failed to get DMA-BUF from buffer
11:36:33.556 [DEBUG] [wlr] [backend/drm/drm.c:423] connector eDP-1: Failed to import buffer for scan-out

message every 100ms on the log

[emersion]

That message is unrelated.

[eternal-sorrow]

Almost reliably reproduces crash every time I close VSCode window.

[bl4ckb0ne]

@eternal-sorrow care to share some logs or stacktraces?

[eternal-sorrow]

@bl4ckb0ne, Well, I need to run sway with debug enabled and gather the log. I tried getting stacktraces with systemd-coredump, but there was nothing meaningful because of an optimized build and lack of debug symbols. Now I've built sway with debug symbols, so when it crashes again, I might be able to get a stacktrace.

[eternal-sorrow]

Nope, didn't get a useful stacktrace even with debug symbols. My stacktrace looks like this:

#0  0x00007f30c69677cc in ?? ()
#1  0x00007ffcf099c010 in ?? ()
#2  0x7afbd8b7b329cb00 in ?? ()
#3  0x0000000000000006 in ?? ()
#4  0x00007f30c5cfae00 in ?? ()
#5  0x00007ffcf099c020 in ?? ()
#6  0x00007f30b4014000 in ?? ()
#7  0x0000000000000001 in ?? ()
#8  0x00007f30c6917292 in ?? ()
#9  0x00007f30c6aadcb0 in ?? ()
#10 0x00007f30c6901472 in ?? ()
#11 0x0000000000000020 in ?? ()
#12 0x0000001c00000780 in ?? ()
#13 0x0000000000000000 in ?? ()

[eternal-sorrow]

For some reason I can't reproduce the crash after I started sway with debug output.

[bl4ckb0ne]

@hissssst can you confirm your issue is fixed in master?

[eternal-sorrow]

Okay, I set up constant debug logging for sway in case I will be able to reproduce the crash, and yes, it happened again. There is nothing unusual in the log though:

82:03:27.201 [INFO] [sway/commands.c:260] Handling command 'kill'
82:03:27.279 [DEBUG] [sway/ipc-server.c:328] Sending window::close event
82:03:27.280 [DEBUG] [sway/tree/arrange.c:263] Usable area for ws: 1920x1052@0,0
82:03:27.280 [DEBUG] [sway/tree/arrange.c:293] Arranging workspace '5' at 0.000000, 0.000000
82:03:27.280 [DEBUG] [sway/desktop/transaction.c:398] Transaction 0x55774f544a70 committing with 2 instructions
82:03:27.280 [DEBUG] [sway/desktop/transaction.c:294] Applying transaction 0x55774f544a70

And this is it. 'kill' command is me closing VSCode window.

[bl4ckb0ne]

What's unusual?

[eternal-sorrow]

Nothing. That's what I've said. But these were the last lines in the log before sway crashed.

[hissssst]

Fixed in master

[eternal-sorrow]

Will there be a hotfix release where this is fixed?

[emersion]

Sway 1.8.1 is planned, yes.

[eternal-sorrow]

Crashes when closing VSCode still occur on 1.8.1. I guess, it's a different bug.

[bl4ckb0ne]

Open a new issue with the stacktrace please

[eternal-sorrow]

I already wrote before that I was unable to get a meaningful stacktrace.