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

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Mon, 2022-03-28 at 09:44 -0700, Bart Schaefer wrote:
> Another possibility that occurs to me is for the values in $jobstates to change.
> 
>      ... The keys are the job numbers and the values
>      are strings of the form 'JOB-STATE:MARK:PID=STATE...'.  The
>      JOB-STATE gives the state the whole job is currently in, one of
>      'running', 'suspended', or 'done'.
> 
> What if JOB-STATE became "parent" in the subshell?  Or something along
> those lines.  I guess that goes back to having to make a deep copy of
> the saved job structure.

I think if can get something that "just works" we'll save quite a lot of
aggravation for ourselves both as users and as zsh-workers.  If there's
nothing too obviously wrong with magically pusthing the rabbit back into
the hat again so it looks like a normal top hat, I'd prefer to try that.

> Incidentally:
> 
> % sleep 10 & print -aC2 ${(kv)jobstates}; (jobs -l; print -aC2 ${(kv)jobstates})
> [1] 69151
> 1  running:+:69151=running
> [1]  + 69151 running    sleep 10
> 1  running:+
> 
> How is it that "jobs -l" still knows the PID from the parent job, but
> $jobstates cannot report it?

Hmm... on my home machine the crash is a bit more sporadic than it was
on the NUC at work, so it's something to do with races rather than a
simple invalid pointer as I originally assumed.  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).  But I can't
see what's different here from jobs.  In both cases, when oldjobtab is
non-NULL, we're scanning from job 1 to the maximum for jobs with stat
and procs non-zero and no STAT_NOPRINT.  Also, signals should be queued
at this point.  So I'm stuck at the moment.

pws