Re: Bogus "no such job" (Re: Preliminary release of 3.0.8 - please test)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

I wrote:

> Bart Schaefer wrote:
> 
> ...
> > 
> > I can believe that a race condition might cause "no such job: 3" once,
> > but twice in a row is impossible.  So the only possible answer is that
> > the one and only job has STAT_NOPRINT set but *not* STAT_SUBJOB, which
> > in turn happens only at exec.c:768 and 806 (in 3.0.8; in 3.1.6-dev-19,
> > exec.c:993 and 1031), both in execpline().  See jobs.c:setprevjob(),
> > which is called from setcurjob().
> 
> The one in 1031 isn't interesting here, it only makes the sub-shells
> created for stopped lists not report their jobs (list_pipe_child is
> non-zero only in those sub-shells). Leaves us with the one in 993.
> This is used to make sure that jobs started for commands which are
> not the first one in a pipeline and jobs started from some kind of 
> pipeline nesting (e.g. in a loop in a pipeline) are not shown.
> 
> Given that, your suggestion:
> 
> > Now, it may be that the right solution is to have setprevjob() ignore
> > jobs that have STAT_NOPRINT set, but I wouldn't want that to mask some
> > more serious job-state problem.  If you have any insights, share 'em.
> 
> seems sensible. But... how can such a job survive when the super-job
> of the (main) pipeline is dead? I wished I could find a way to
> reproduce it.

I've played some more yesterday evening/night but still couldn't get
it to happen (with dev-19, that is).

Geoff, do you remember what you did before you got that message? Did
you kill some job/process? What (kind of) commands did you suspend?
Pipes with lists in them, commands that do some kind of signal
handling? (Yes, I'm guessing wildly...)


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx