wayfire
wayfire copied to clipboard
wayfire pereodical crashes when hotswapping outputs
Describe the bug when i dock/undock my notebook wayfire has a chance to crash. also this happens when i put/take sleeping notebook to/from dock and enabling it i have running kanshi for managing outputs
To Reproduce
- enable kanshi
- hotswap some monitors, try to do this in sleep mode and wake after changes
- wayfire sometimes crashing
Expected behavior nothing bad happens)
Screenshots or stacktrace last two times i was prepared and started collecting some logs of wayfire) wayfire_log2021-05-22-10-37-35.txt wayfire_log2021-05-21-07-58-04.txt
Wayfire version git from 4c5e5fdabf98ea22cb330db3c6b37e749db44218 commit (19 may) with my own plugin
i can see that this is something strange with output management by wayfire itself, and also i notified that the same DP outputs detecting as new with increased numbers, so maybe the DP support is a little bit fucked, and this is an issue) P.S. also there is quite annoying thing when wayfire live updating its config and my outputs messing, so i need to restart kanshi after this maybe i can somehow tell wayfire to not messing with outputs at all and let kanshi do its job without interruptions?) P.P.S. it would be cool also to somehow tell wayfire after output switching which output use to translate windows from disabled one
#1202 might be useful if you're using kanshi, that way Wayfire will not try to mess up with kanshi when the config changes.
last two times i was prepared and started collecting some logs of wayfire) wayfire_log2021-05-22-10-37-35.txt wayfire_log2021-05-21-07-58-04.txt
I looked into these stacktraces, they are different which is strange. I suspect that there is memory corruption going on. Can you maybe compile with address sanitizer turned on, reproduce again and send the new log here?
last two times i was prepared and started collecting some logs of wayfire) wayfire_log2021-05-22-10-37-35.txt wayfire_log2021-05-21-07-58-04.txt
I looked into these stacktraces, they are different which is strange. I suspect that there is memory corruption going on. Can you maybe compile with address sanitizer turned on, reproduce again and send the new log here?
just found some time to do so, also update wayfire, but it won't builds now =D
@ammen99
enable sanitizer like this?
meson build -Db_sanitize=memory
and then grab logs like this?
wayfire 2>&1>wayfire.log
didn't know pretty much anything about modernish build systems tho)
@ammen99 enable sanitizer like this?
meson build -Db_sanitize=memory
and then grab logs like this?wayfire 2>&1>wayfire.log
didn't know pretty much anything about modernish build systems tho)
I am using -Db_sanitize=address,undefined, idk about memory.
Removing preserve-output
from active plugins seems to prevent this crash (at least I had several successful display hotplugs in a row so far after disabling the module).
Recently crashes became much more frequent, hypothetically due some dependencies upgrades in Debian testing. I tried upgrading to wayfire 0.7.5 and could not even start it up, it crashed right away with the same src/main.cpp:141
segfault. Removing preserve-output
fixed this. Usefulness of the plugin is quite limited anyway.
No, disabling preserve-output
just prevented immediate crash on startup in 0.7.5. Random crashes on output events still occur.
Does anyone (experiencing these crashes) has by any chance autorandr installed and xwayland enabled?
Autorandr has udev hooks to run on output hotplug events, might be interfering via xwayland. I've uninstalled it and got no more random crashes (about a week so far).
preserve-output
still consistently causes crash on launch though.
Got another crashy situation with the same src/main.cpp:141
segfault
This time when running unison-gtk (as xwayland client): in some sync sessions it may trigger wm crash, sometimes two attempts in a row, but not after a successful sync. As if it depends on how many files are being displayed in a sync session.
EE 07-01-23 01:31:32.864 - [src/view/xwayland.cpp:535] new xwayland surface (null) class: (null) instance: (null)
EE 07-01-23 01:31:32.983 - [src/view/xwayland.cpp:535] new xwayland surface (null) class: (null) instance: (null)
EE 07-01-23 01:31:32.984 - [src/view/xwayland.cpp:535] new xwayland surface (null) class: (null) instance: (null)
EE 07-01-23 01:31:32.987 - [src/view/xwayland.cpp:818] new unmanaged xwayland surface (null) class: (null) instance: (null)
EE 07-01-23 01:31:47.482 - [src/view/xwayland.cpp:535] new xwayland surface (null) class: (null) instance: (null)
EE 07-01-23 01:31:48.101 - [src/view/xwayland.cpp:818] new unmanaged xwayland surface (null) class: (null) instance: (null)
EE 07-01-23 01:31:48.125 - [xwayland/xwm.c:1526] xcb error: op 12:0, code 2, sequence 49603, value 0
EE 07-01-23 01:31:48.413 - [xwayland/xwm.c:1526] xcb error: op 18:0, code 3, sequence 49611, value 8391643
EE 07-01-23 01:31:48.413 - [xwayland/xwm.c:1526] xcb error: op 18:0, code 3, sequence 49612, value 8391643
EE 07-01-23 01:31:48.413 - [xwayland/xwm.c:1526] xcb error: op 18:0, code 3, sequence 49614, value 8391255
EE 07-01-23 01:31:48.418 - [xwayland/xwm.c:1526] xcb error: op 18:0, code 3, sequence 49619, value 8391255
EE 07-01-23 01:31:48.419 - [xwayland/xwm.c:1526] xcb error: op 18:0, code 3, sequence 49620, value 8391255
II 07-01-23 01:31:49.104 - [wayland] error in client communication (pid 2494164)
II 07-01-23 01:31:49.104 - [xwayland/server.c:218] Restarting Xwayland
(EE)
Fatal server error:
(EE) [destroyed object]: error -1: surface was destroyed before its role object
(EE)
EE 07-01-23 01:31:49.107 - [src/main.cpp:141] Fatal error: Segmentation fault
II 07-01-23 01:31:49.109 - [xwayland/server.c:108] Starting Xwayland on :0
EE 07-01-23 01:31:49.119 - #1 wf::print_trace(bool) ??:?
(WW) Option "-listen" for file descriptors is deprecated
Please use "-listenfd" instead.
(WW) Option "-listen" for file descriptors is deprecated
Please use "-listenfd" instead.
EE 07-01-23 01:31:49.264 - #2 __restore_rt libc_sigaction.c:?
EE 07-01-23 01:31:49.271 - #3 wlr_xwayland_destroy ??:?
EE 07-01-23 01:31:49.276 - #4 wlr_xwayland_destroy ??:?
EE 07-01-23 01:31:49.281 - #5 wlr_surface_destroy_role_object ??:?
EE 07-01-23 01:31:49.286 - #6 wlr_surface_destroy_role_object ??:?
EE 07-01-23 01:31:49.291 - #7 ?? ??:0
EE 07-01-23 01:31:49.295 - #8 wl_event_loop_get_destroy_listener ??:?
EE 07-01-23 01:31:49.299 - #9 wl_array_copy ??:?
EE 07-01-23 01:31:49.303 - #10 wl_client_destroy ??:?
EE 07-01-23 01:31:49.308 - #11 wl_client_destroy ??:?
EE 07-01-23 01:31:49.312 - #12 wl_event_loop_dispatch ??:?
EE 07-01-23 01:31:49.316 - #13 wl_display_run ??:?
EE 07-01-23 01:31:49.323 - #14 main ??:?
EE 07-01-23 01:31:49.395 - #15 __libc_start_call_main ../sysdeps/x86/libc-start.c:74
EE 07-01-23 01:31:49.467 - #16 call_init ../csu/libc-start.c:128
EE 07-01-23 01:31:49.474 - #17 _start ??:?
(EE) could not connect to wayland server
Looking at the original issue discussed here, I am pretty sure it was resolved in wayfire-git. If it still happens, please open a new issue with a new stacktrace, since many things have changed.
The bug by @Vladimir-csp looks like a crash of Xwayland, which leads to a crash caused by wlroots, maybe it has been fixed in newer wlroots versions.