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

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

[Sven Wischnowsky]

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@informatik.hu-berlin.de

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

[Geoff Wing]

Sven Wischnowsky <wischnow@informatik.hu-berlin.de> typed:
: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...)

Job 2 was vim; job 1 was make (BSD make ~= pmake) or maybe another
vim job.  I've got no memory of running a third job, though it may
have been something like ``cvs log <somefile> | less'' or
``cvs status |& fgrep Status | fgrep -v Up-to''.  I'm sure I never
had four jobs going.  Unfortunately I didn't attach a debugger or
core dump it so I have no ability to query values from it in that
state.  It's very rare (obviously) though I've either got deja vu
or I've seen it before at least once (and it would have been quite
a while ago (a year? more maybe) so I suspect it's not from any
recent changes).

Regards,
-- 
Geoff Wing : <gcw@pobox.com>     Work URL: http://www.primenet.com.au/
Rxvt Stuff : <gcw@rxvt.org>      Ego URL : http://pobox.com/~gcw/
Zsh Stuff  : <gcw@zsh.org>       Phone   : (Australia) 0413 431 874

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

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Mar 3,  2:55am, Geoff Wing wrote:
> } Subject: Re: Preliminary release of 3.0.8 - please test
> }
> } Bart Schaefer <schaefer@candle.brasslantern.com> typed:
> } :On Feb 29, 10:33am, Geoff Wing wrote:
> } :} Subject: Re: Preliminary release of 3.0.8 - please test
> } :} After some initial usage, got it into a state of:
> } :} % %
> } :} fg: no such job: 3
> } :} % %%
> } :} fg: no such job: 3
> } :} % fg
> } :} fg: no current job
> } :} % jobs
> } :} %
> } :Hrm.  The job handling code is now identical to 3.1.6-dev-19, so if you
> } :can get 3.0.8 into that state theres a problem for 3.1.6 as well.
> } 
> } I'm thinking that getjob() may need a setcurjob() before it checks curjob.
> 
> Since Sven has been incommunicado for a couple of days, I tried to look
> into this myself in more detail.  The only two places where getjob() is
> called are from bin_kill(), and from bin_fg() *after* the setcurjob()
> that you noted.
> 
> 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.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

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

[Bart Schaefer]

On Mar 3,  2:55am, Geoff Wing wrote:
} Subject: Re: Preliminary release of 3.0.8 - please test
}
} Bart Schaefer <schaefer@candle.brasslantern.com> typed:
} :On Feb 29, 10:33am, Geoff Wing wrote:
} :} Subject: Re: Preliminary release of 3.0.8 - please test
} :} After some initial usage, got it into a state of:
} :} % %
} :} fg: no such job: 3
} :} % %%
} :} fg: no such job: 3
} :} % fg
} :} fg: no current job
} :} % jobs
} :} %
} :Hrm.  The job handling code is now identical to 3.1.6-dev-19, so if you
} :can get 3.0.8 into that state theres a problem for 3.1.6 as well.
} 
} I'm thinking that getjob() may need a setcurjob() before it checks curjob.

Since Sven has been incommunicado for a couple of days, I tried to look
into this myself in more detail.  The only two places where getjob() is
called are from bin_kill(), and from bin_fg() *after* the setcurjob()
that you noted.

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().

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.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com