Re: 3.0.6-pre-5 problem

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

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