From: Peter Stephenson <firstname.lastname@example.org>
Subject: Re: Probabilistic crash on zsh 5.9 on x86_64
Date: Thu, 13 Apr 2023 14:19:21 +0100 (BST) [thread overview]
Message-ID: <email@example.com> (raw)
> On 13/04/2023 14:02 Jun. T <firstname.lastname@example.org> wrote:
> > 2023/04/13 20:12、Peter Stephenson <email@example.com>のメール:
> > "watch" says the real culprit is this unsettrap() in starttrapscope().
> > I guess the save and restore action here needs a corresponding
> > useeprog / freeprog, not sure the best way of doing that yet.
> As I wrote before, the entire 'struct shfunc' is freed by
> shfunctab->freenode(shf) (signals.c:982), or freeshfuncnode(shf).
> I think it is not just the problem of the reference count of Eprog
> Or maybe I misunderstood your post.
"Freeing" really means reducing the reference count and then actually
freeing the structure only when the reference count hits zero. So
because we want to keep this structure, the reference count shouldn't
be zero at this point (it shouldn't ever be allowed to go to zero
for a permanently allocated structure visible to user code, hence the
DPUTS test), and if it isn't then the problem goes away --- this
becomes just a normal function call.
However, it's not trivial because of the way we save and restore
TRAPEXIT (and possibly other traps). We do this because the
TRAPEXIT shouldn't be running from within a nested function call.
So what we should logically do is take the code chunk out of the
trap list but marked in such a way that it won't get actually freed,
because we're going to put it back again later, and because someone
may access the same structure meanwhile (as it's permanently
allocated --- the whole point of reference counts being that it's
hard to know for sure who's referring to which code chunk at any
Unfortunately, it looks like this process is more complicated than
that, involving actual copies, so finding a place to bump the
reference count and then later reduce it again (which would free
the structure if it actually wasn't needed any more at that second
point) isn't trivial, and it's quite possible there is another solution
not involving reference counts.
Hope that's clearer but I'm not sure it is...
next prev parent reply other threads:[~2023-04-13 13:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-08 17:28 zsh bug report throwaway email thing
2023-04-08 21:36 ` Mikael Magnusson
2023-04-11 16:14 ` Jun. T
2023-04-11 16:29 ` Peter Stephenson
2023-04-13 10:47 ` Peter Stephenson
2023-04-13 11:12 ` Peter Stephenson
2023-04-13 13:02 ` Jun. T
2023-04-13 13:19 ` Peter Stephenson [this message]
2023-04-13 14:03 ` Peter Stephenson
2023-04-13 14:13 ` Peter Stephenson
2023-04-13 16:40 ` Jun. T
2023-04-13 16:55 ` Peter Stephenson
2023-04-14 8:29 ` Peter Stephenson
2023-04-14 12:21 ` Mikael Magnusson
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 \
* 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).