Summary: | Weston crash when weston-desktop-shell and weston-keyboard missing | ||
---|---|---|---|
Product: | Wayland | Reporter: | Pekka Paalanen <ppaalanen> |
Component: | weston | Assignee: | Pekka Paalanen <ppaalanen> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | stu_dby |
Version: | 1.5.0 | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Pekka Paalanen
2014-08-22 16:31:55 UTC
Well, the problem here is a quite tricky race condition. If weston-desktop-shell isn't found (or dies), desktop-shell will do two things concurrently -- emitting the client's destroy signal and try to launch shell client again. If the destroy signal is emitted first, everything is okay. If a new shell client is launched first (calling launch_desktop_shell_process), things will go wrong because the shell->child.client_destroy_listener is registered the second time, breaking the listening list of the dead client's destroy signal. When destroy signal is finally emitted, iteration on the broken list will cause illegal invocation and the program will crash. I guess the missing of two programs only increases the chance of race and sometimes weston won't crash in my observation. I'll come up with a patch soon. I've just found that the only thing desktop_shell_client_destroy() do is setting shell->child.client to NULL and that's also done in desktop_shell_sigchld(). I think just getting rid of desktop_shell_client_destroy() and the client's destroy listener will solve this problem (and potentially many others). Someone on irc (rawoul) explained to me that the destroy listener is actually required because if it doesn't set client = NULL then something else might try to free it later. This apparently can lead to a segfault on shutdown - I've not tried to reproduce this issue myself. I've also tried removing the sigchld handler and pushing all its functionality into the destroy listener - that fails in other interesting ways: - p->cleanup is always called, even if null. (need a no-op handler or to relax that constraint) - if the destroy handler tries to add the destroy listener to the newly launched client's destroy notifiers it'll screw up the current pass through the old process's destroy handler list. - the process struct (shell->child.process) is having its pid set to 0 in the destroy handler - this results in an incorrect log message when weston's sigchld handler can't find the dead process' pid. I've tried deferring the call to launch_desktop_shell_process() with wl_event_loop_add_idle() but I don't know how to convince myself that the idle timer can't ever launch the new process before compositor.c processes the sigchld. (which would again result in a spurious unknown process error in the log) I sent a series, that supposedly fixes this and another related issue: http://lists.freedesktop.org/archives/wayland-devel/2014-August/016901.html The three patches are upstream now. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.