When weston-launch is killed with SIGINT or SIGTERM, weston-launch exits as expected. However, attaching to the desktop-shell process prior to killing weston-launch reveals that desktop-shell segfaults (100% of the time).
Further, the segv is masked. Running `echo $?` immediately after killing weston-launch does not give any indication of the desktop-shell segv. There is no stdout or stderr log messages indicating that an error occurred. This is undesired behavior.
Steps to reproduce:
1. Run as a normal user (member of weston-launch group):
2. Attach gdb to the desktop-shell process, continue execution
3. Kill weston-launch, either with SIGTERM or SIGINT
4. gdb will catch a segv
It is expected that weston-launch somehow communicate an unclean exit from its shell (or modules).
In actuality, whatever launched weston-launch is not informed of the unclean exit.
State of (select components of) the s/w stack:
wayland (master) heads/master-0-g7094441
mesa (HEAD) mesa-9.1.3-0-gf32ec82
cairo (HEAD) 1.12.8-0-gcc16291
weston (master) heads/master-0-ga58290b
Created attachment 81035 [details]
backtrace of desktop-shell segv
The segv scenario is only exposed when weston is built with cairo-gl support. Lowering severity.
This was a mesa bug:
Author: Kristian Høgsberg <email@example.com>
Date: Tue Jun 18 16:53:46 2013 -0400
wayland: Handle global_remove event as well
We need to set up a handler for the global_remove event that gets sent
out when a global gets removed. Without the handler we end up calling
a NULL pointer.
NOTE: This is a candidate for the stable branches.
Signed-off-by: Kristian Høgsberg <firstname.lastname@example.org>
(added EGL component for mesa, moved bug there)
I can verify your fix corrects the reported issue, so I'm setting status to "verified."
(In reply to comment #3)
> This was a mesa bug:
> commit 712269d6744a8849d1d0cf01fa0132d969b79ed4
> Author: Kristian Høgsberg <email@example.com>
> Date: Tue Jun 18 16:53:46 2013 -0400
> wayland: Handle global_remove event as well
> We need to set up a handler for the global_remove event that gets sent
> out when a global gets removed. Without the handler we end up calling
> a NULL pointer.
> NOTE: This is a candidate for the stable branches.
> Signed-off-by: Kristian Høgsberg <firstname.lastname@example.org>
on Jan 21, 2017 at 02:13:19.
(provided by the Example extension).