From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22621 invoked by alias); 28 Dec 2013 23:02:37 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32195 Received: (qmail 19280 invoked from network); 28 Dec 2013 23:02:21 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <131228150234.ZM27671@torch.brasslantern.com> Date: Sat, 28 Dec 2013 15:02:34 -0800 X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Possible signal handling issues MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Both of these have been around since at least 4.2.0. Consider this script: --- snip --- sleep 20 & TRAPINT() { set -x; kill -INT $$ } wait --- snip --- Run that in the foreground, kill it with ctrl+c, and watch the infinite loop. Something to do with the "wait" command allows the INT to be re- queued for handling even when it is sent from inside an INT trap. The signal_suspend() in zwaitjob() is constantly re-interrupted and never returns. I'm uncertain whether this next one is actually a bug. This is from Chris Johnson's question on zsh-users: --- snip --- sleep 10000 & longpid=$! sleepkill() { sleep 20 print "timed out" kill $longpid } sleepkill & sleeppid=$! TRAPINT() { set -x kill $longpid #kill $sleeppid # test 1 #kill -- -$sleeppid # test 2 #kill -HUP -$$ # test 3 } sleep 30 -- snip -- I avoided using "wait" as the last line there to show it's not related to the previous bug. If we run that script and then interrupt with ctrl+c, the entire sleepkill function is left running in the background. That's probably correct because the monitor option is off in scripts so the hup option does not apply. Uncomment test 1. Now the subshell started for sleepkill is terminated, but "sleep 20" is left running. This seems very odd to me, because that sleep was never backgrounded relative to the sleepkill function. Remove test 1 and uncomment test 2 and you get a "no such process" error, which indicates that sleepkill is not a "process group leader" so none of its children receive its signals. Uncomment test 3 which signals the whole process group of the original script, and everything gets killed off. Should the subshell be propagating that signal in the first test?