Crashes when opening clients

[ap29600]

I have experienced some crashes when opening clients (seems to happen more often if firefox is open). sadly 4 out of 5 times i was sending errors to /dev/null (that's not very helpful) but i recorded the last one, here it is:
dwl: types/xdg_shell/wlr_xdg_surface.c:15: wlr_xdg_surface_from_wlr_surface: Assertion `wlr_surface_is_xdg_surface(surface)' failed. thread 'thread 'mainmain' panicked at '' panicked at 'failed to read wayland events: Broken pipe (os error 32)failed to read wayland events: Broken pipe (os error 32)', ', <::std::macros::panic macros><::std::macros::panic macros>::55:6 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread ':main6 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ' panicked at 'failed to read wayland events: Broken pipe (os error 32)', <::std::macros::panic macros>:5:6 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'failed to read wayland events: Broken pipe (os error 32)', <::std::macros::panic macros>:5:6 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I will run it with RUST_BACKTRACE enabled as suggested, is there anything else I should provide?
This is on arch linux, wlroots version 0.10.1-1 and wayland-protocols version 1.20-1

[ap29600]

Here I am again after a quick experiment, I just opened 5 instances of alacritty and this is the result: when switching client with focus following the mouse dwl crashes producing this output:
dwl.log
(edited the comment, i had previously copy-pasted the log but the formatting broke)

[djpohly]

Thanks for the report! Most of the text in that log is alacritty complaining that the compositor went down - the useful bit from dwl is assertion on the first line, which is coming from focusclient. Are there steps I could use to reliably reproduce the bug here? (alacritty hasn't given me problems in my testing so far.)

focusclient needs some rewriting anyway with a better understanding of Wayland/xdg_shell invariants, so this might end up being fixed tangentially if we don't pin it down now.

[ap29600]

oh, I didn't realize the logs from children processes would carry over, though that does make sense.
As to how to reproduce the bug, I really didn't do anything weird, this was dwl launched directly from tty, no display manager, alacritty launched with no cli arguments, and the alacritty.yml only contains font size and family. It does seem weird that the window decorations were rendered incorrectly (the windows were aligned relative to the top edge, with the titlebar out of the reserved area and a corresponding gap at the bottom of the window, which might be a completely different bug to report) and this only happened when I had more than about three-ish clients open, which may have something to do with the window stack giving errors when passing a certain threshold, assuming the stack is actually a structure in the code and not an abstraction, I will have to take a look at the actual code tomorrow so I can clear that up.
Always glad to help.

[ap29600]

I should also mention that the laptop I tested this on has a Ryzen 5 processor with Vega graphics, which unfortunately has given me a bit of a headache regarding stability (Xorg sometimes locks up under heavy load and I have to switch to a tty and back) so it might well be the video driver acting up and the compositor not being robust enough to recover from that gracefully?

[djpohly]

Ah, there's the key phrase: "window decorations." dwl isn't yet an expert at handling and/or killing client-side decorations (see #3), but it's more successful under wlroots-git than under wlroots-0.10.1. Alternatively, you can set window.decorations="none" in alacritty.yml.

[djpohly]

Or, actually... try the latest dwl commit with your current setup to see if it behaves better!

[ap29600]

well, that was fast! The CSD are still not rendered correctly, but they no longer cause crashes. To confirm your hypothesis, I also tried the old build with them off and it worked like a charm, I will now try wlroots-git to see if it makes a difference.

[ap29600]

No difference with wlroots-git, closing the issue