From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7308 invoked from network); 25 Jun 1999 09:04:03 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 Jun 1999 09:04:03 -0000 Received: (qmail 6681 invoked by alias); 25 Jun 1999 09:03:33 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6844 Received: (qmail 6674 invoked from network); 25 Jun 1999 09:03:32 -0000 From: "Bart Schaefer" Message-Id: <990625090315.ZM3925@candle.brasslantern.com> Date: Fri, 25 Jun 1999 09:03:15 +0000 In-Reply-To: <199906250622.IAA32689@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: 3.0.6-pre-5 problem" (Jun 25, 8:22am) References: <199906250622.IAA32689@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: Sven Wischnowsky , zsh-workers@sunsite.auc.dk Subject: Re: 3.0.6-pre-5 problem MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 25, 8:22am, Sven Wischnowsky wrote: } Subject: Re: 3.0.6-pre-5 problem } } Jos Backus wrote: } > Interestingly, this backtrace looks quite different from the first one. } } (This fact irritates me mightily.) The backtrace isn't really all that different, it just dies sooner with debugging enabled. } Anyway, I couldn't reproduce it but there is no harm in adding some } security code to execpline(). I guess this will not apply cleanly to } 3.0.6, though. I think this patch (6838) should NOT be applied, and we need a different one instead. Look here: } - for (pn = jobtab[jn->other].procs; pn; pn = pn->next) } - if (WIFSTOPPED(pn->status)) } - break; } + if (jn->stat & STAT_SUPERJOB) { } + for (pn = jobtab[jn->other].procs; pn; pn = pn->next) } + if (WIFSTOPPED(pn->status)) } + break; When I run this on linux inside gdb, it crashes on jobtab[jn->other], and no wonder ... jn->other is a *process id*. jobtab[] is only 50 elements long; in my case jn->other == 3819, which puts jobtab[jn->other] way out in the middle of nowhere. Now, I see from the comments in zsh.h that jn->other is sometimes supposed to be a job number, and sometimes supposed to be a PID, which I think is a really bad style of overloading ... but style aside, there appear to be cases in execpline() where it's being treated as a subjob number when it really is a process ID. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com