Re: $pipestatus broken?

[Bart Schaefer <schaefer@brasslantern.com>]

On Dec 10,  1:48pm, Frank Terbeck wrote:
} Subject: Re: $pipestatus broken?
}
} You can actually dumb this down to:
} 
} [snip]
} : | while read a; do
}     :
} done
} print "${pipestatus[@]}"
} [snap]
} 
} It (pipestatus just containing a single "1") seems to happen less
} frequently with this simpler loop, but still in the range of 5% of the
} invocations on my machine.

With that loop, I get a single "1" 100% of the time unless I attach to
the process with GDB, in which case it becomes random.

I traced this down to update_job().  At this line:

Breakpoint 5, update_job (jn=0x9415894) at ../../zsh-4.0/Src/jobs.c:504
504	    if (job == thisjob && (jn->stat & STAT_DONE)) {

There are two entries in the job table; job = 1 and thisjob = 2, so we
skip updating $pipestatus.  I don't know where the "1" value in the
first element of pipestatus comes from, though.

In this case update_job() is being called from wait_for_processes() via
zhandler() while the shell is blocked in bin_read().

Interestingly, in the case I trapped with GDB, we're waiting for PID
6193:

492		if (findproc(pid, &jn, &pn, 0)) {

(gdb) p pid
$16 = 6193

But that job is not anywhere in jobtab -- the closest is jobtab[1]:

(gdb) p jobtab[1]
$19 = {gleader = 6192, other = 0, stat = 1097, pwd = 0x0, procs = 0x9428028, 
  auxprocs = 0x0, filelist = 0x0, stty_in_env = 0, ty = 0x0}

The procs pointer there points to a one-element linked list containing
only PID 6192.  So where did 6193 come from, and why is it not in the
job table?