From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17071 invoked by alias); 10 Dec 2011 14:58:50 -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: 29975 Received: (qmail 14130 invoked from network); 10 Dec 2011 14:58:48 -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 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <111210065833.ZM6198@torch.brasslantern.com> Date: Sat, 10 Dec 2011 06:58:33 -0800 In-reply-to: <877h24zj69.fsf@ft.bewatermyfriend.org> Comments: In reply to Frank Terbeck "Re: $pipestatus broken?" (Dec 10, 1:48pm) References: <87borgzkap.fsf@ft.bewatermyfriend.org> <877h24zj69.fsf@ft.bewatermyfriend.org> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: $pipestatus broken? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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?