Re: Crash on jobstates since workers/49783 (commit 6a8aa2a)

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

> On 29 March 2022 at 04:49 Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Mon, Mar 28, 2022 at 12:53 PM Peter Stephenson
> <p.w.stephenson@xxxxxxxxxxxx> wrote:
> >
> > When I simply print
> > jobstates and it does crash I'm seeing what looks like the process
> > number of the subshell process appear right before the crash (i.e. it's
> > typically one more than the sleep that was just started).
> 
> This?
> 
> diff --git a/Src/jobs.c b/Src/jobs.c
> index 18e43f03c..83ffdbde5 100644
> --- a/Src/jobs.c
> +++ b/Src/jobs.c
> @@ -1718,6 +1718,12 @@ clearjobtab(int monitor)
>         /* Don't report any job we're part of */
>         if (thisjob != -1 && thisjob < oldmaxjob)
>             memset(oldjobtab+thisjob, 0, sizeof(struct job));
> +
> +       /* oldmaxjob is now the size of the table, but outside
> +        * this function, it's used as a job number, which must
> +        * be the largest index available in the table.
> +        */
> +       --oldmaxjob;
>      }

Yes, that seems like it's doing the right thing.

I'll add documentation and tests to the patch for the other half and remove
changes to job state querying.

pws