help / color / mirror / code / Atom feed
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: zsh-workers@zsh.org
Subject: Re: Crash on jobstates since workers/49783 (commit 6a8aa2a)
Date: Mon, 28 Mar 2022 20:52:01 +0100	[thread overview]
Message-ID: <1e36a19a15237624412bc502ebfcf99034dfbb79.camel@ntlworld.com> (raw)
In-Reply-To: <CAH+w=7Zbp2DYnmfseS=6zvkh6Raa036HntbqTrOdRNL5391vJQ@mail.gmail.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.


  reply	other threads:[~2022-03-28 19:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-25 22:32 Bart Schaefer
2022-03-27  5:34 ` Bart Schaefer
2022-03-28  8:47   ` Peter Stephenson
2022-03-28 14:49     ` Peter Stephenson
2022-03-28 15:09       ` Bart Schaefer
2022-03-28 16:14         ` Peter Stephenson
2022-03-28 16:44           ` Bart Schaefer
2022-03-28 19:52             ` Peter Stephenson [this message]
2022-03-29  3:49               ` Bart Schaefer
2022-03-29  9:08                 ` Peter Stephenson
2022-03-29 13:31                   ` Peter Stephenson
2022-03-29 15:39                     ` Bart Schaefer
2022-03-29 15:36                   ` Bart Schaefer
2022-03-29 15:41                     ` Peter Stephenson
2022-03-28 15:13     ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1e36a19a15237624412bc502ebfcf99034dfbb79.camel@ntlworld.com \
    --to=p.w.stephenson@ntlworld.com \
    --cc=zsh-workers@zsh.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).