Re: killing suspended jobs makes zsh hang after 47d1215

[Peter Stephenson <Peter.Stephenson@xxxxxxx>]

On Sun, 12 Jun 2011 18:53:39 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Jun 13,  4:02am, Pan Tsu wrote:
> }
> }   % cat | cat &
> }   [1] 91580 97756
> }   [1]  + suspended (tty input)  cat | cat
> }   % %
> }   [1]  + continued  cat | cat
> }   ^C
> }   load: 0.06 no foreground process group
> } 
> }   (gdb) p pn->status
> }   $1 = 19
> }   (gdb) p WIFSIGNALED(pn->status)
> 
> So I begin to suspect that what we really want here is
> 
> Index: Src/jobs.c
> --- Src/jobs.c.~1.83.~	2011-06-12 08:05:58.000000000 -0700
> +++ Src/jobs.c	2011-06-12 18:51:37.000000000 -0700
> @@ -190,7 +190,7 @@
>  	     * to return in a different job.
>  	     */
>  	    if (pn->pid == pid && (pn->status == SP_RUNNING ||
> -				   WIFSTOPPED(pn->status))) {
> +				   !WIFEXITED(pn->status))) {
>  		*pptr = pn;
>  		*jptr = jobtab + i;
>  		return 1;

This is getting confusing.  WIFSIGNALED() indicates the process exited,
but on a signal rather than due to an exit call.  Why would we need to
distinguish those two cases?

It may be we need to distinguish the callers.  The original bug was when
a process that had exited, that was part of a job that had not yet
terminated, was being used inappropriately (see zsh-workers/28965).  In
this case it appears that under similar circumstances we need the
terminated job.  What is it in the current case that means we need the
process number even though the process has exited?

-- 
Peter Stephenson <pws@xxxxxxx>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog