Created attachment 77285 [details] gdb log 1 The weston-launch program always crashes with a SIGHUP (Hangup) regardless of how Weston exits. The SIGHUP always occurs during the call to pam_end() but with various locations within that call. See attached gdb backtraces for more details. Was able to verify this on two separate Fedora 17 (64 bit) OS's. However, could not produce the issue on the Ubuntu OS. S/W Stack --------------- wayland (master) heads/master-0-g728b641 drm (master) heads/master-0-gca678bc macros (master) heads/master-0-gc98b41d glproto (master) heads/master-0-g8e3407e dri2proto (master) heads/master-0-gead89ad mesa (master) heads/master-0-g1165ff1 kbproto (master) heads/master-0-gf7022f5 libX11 (master) heads/master-0-gf49bb2d libxkbcommon (master) heads/master-0-gbb620df pixman (master) heads/master-0-gd8ac35a cairo (master) heads/master-0-gfdec6b3 weston (master) heads/master-0-g57edf7f see attached yum package list, too. Steps ----- 1. In terminal A, execute 'weston-launch' 2. In terminal B, execute 'sudo gdb -p <weston-launch PID>' 3. In terminal B (gdb session), type 'c' to continue weston-launch process 4. In terminal C, execute 'pkill -15 -x weston' (try other signals, too) 5. In terminal B (gdb session), observe that gdb detected SIGHUP 6. In terminal B (gdb session), type 'q' to exit gdb debugging session 7. In terminal A, observe that "Hangup" is printed to console 8. In terminal A, execute 'echo $?' and observe that it prints "129"
Created attachment 77286 [details] gdb log 2
Created attachment 77287 [details] gdb log 3
Created attachment 77288 [details] system installed packages
I really don't know about this one, my guess is that there's a problem/race between pam and systemd and that systemd closes our controlling tty somewhere in pam_end() for some reason. Maybe we're expected to handle SIGHUP when we're talking to pam like this...
Each of the signals I send to the weston process are reported as "caught" in weston-launch stdout, last stdout message is "Hangup", unless otherwise noted. Here's what I get when killing the weston process with various signals: * kill -s SIGHUP <weston pid>: weston-launch $? = 129 * kill -s SIGINT <weston pid>: weston-launch $? = 0 * kill -s SIGQUIT <weston pid>: weston-launch $? = 0 * kill -s SIGILL <weston pid>: weston-launch $? = 129 - no stdout indicating catch, framebuffer hangs, weston-launch needs to be re-executed to bring back * kill -s SIGABRT <weston pid>: weston-launch $? = 129 * kill -s SIGFPE <weston pid>: weston-launch $? = 129 - no stdout indicating catch, framebuffer hangs, weston-launch needs to be re-executed to bring back * kill -s SIGSEGV <weston pid>: weston-launch $? = 129 * kill -s SIGTERM <weston pid>: weston-launch $? = 129
Continuing from comment 5, * kill -s SIGKILL <weston pid>: weston-launch $? = 19
commit 18684d442ef87ab857dcda0b9785c328b3da2298 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Mon Jul 22 11:59:18 2013 -0700 weston-launch: Ignore sighup When our session terminates all processes get a SIGHUP. We need to ignore that in weston-launch and stay around to help weston shut down properly. https://bugs.freedesktop.org/show_bug.cgi?id=63004
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.