Applications are crashed out instead of being closed
dodoradio opened this issue · comments
When applications are closed in asteroid-launcher, they crash, causing log messages such as
May 01 19:43:49 koi asteroid-launcher[471]: The Wayland connection broke. Did the Wayland compositor die?.
@MagneFire has identified the problem as https://github.com/AsteroidOS/lipstick/blob/master/src/compositor/lipstickcompositor.cpp#L279 , which calls https://github.com/giucam/qtwayland-1/blob/master/qtwayland/src/compositor/wayland_wrapper/qwlcompositor.cpp#L326 .
Looking at the blame, this was added in AsteroidOS/lipstick@c624f32 .
I haven't yet managed to figure out exactly what the wl_client_destroy function in there does, but something seems to be getting destroyed in a way that violates the wayland spec, which results in the application crashing. Magnefire suggests that the surface is destroyed. I suspect that the entire libwayland client interface is being destroyed.
Most applications close themselves when their last window is closed (or, if they don't, then they're doing it intentionally, eg. when they minimise to systray). Therefore, we should be closing the application's window and then letting it clean itself up, but I haven't yet figured out exactly how to do this. The wayland docs for this behaviour aren't super clear.
A partial fix has been applied in the form of AsteroidOS/lipstick#20 , however this doesn't seem to be reliable.
After a session restart (systemctl restart user@1000) the first app closed seems to exit correctly, exit code 0. Subsequent apps randomly give either code 1 or 6.
here is an example of the logs we're getting with exit code 1
Aug 07 14:18:12 medaka asteroid-launcher[4264]: The Wayland connection broke. Did the Wayland compositor die?
Aug 07 14:18:12 medaka /usr/libexec/mapplauncherd/booster-qt5[4258]: Boosted process (pid=4264) exited with status 1
Aug 07 14:18:12 medaka asteroid-launcher[4344]: invoker: Invoking execution: '/usr/lib/asteroid-flashlight.so'
The first line seems to be from the app itself. It seems that it still sees the wayland connection being destroyed as before this commit, but I'm not sure what's causing that to happen, as @neochapay 's code looks to be correct.