From: Pip Cet <pipcet@protonmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com,
yantar92@posteo.net, emacs-devel@gnu.org
Subject: Re: MPS: a random backtrace while toying with gdb
Date: Tue, 02 Jul 2024 07:55:26 +0000 [thread overview]
Message-ID: <CT5MbHCspJZE5id507qGzJXm0wcGmmPg7GX4fDVsC1C4ZDbXMceItHgG9ZZO8Rra9CJDDw8HsClcrkL7kMqu7Kty1qFQ6sgdnhohdALWIbQ=@protonmail.com> (raw)
In-Reply-To: <86h6d9dlyg.fsf@gnu.org>
On Monday, July 1st, 2024 at 18:08, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Mon, 01 Jul 2024 17:27:49 +0000
>
> > From: Pip Cet pipcet@protonmail.com
> > Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, yantar92@posteo.net, emacs-devel@gnu.org
>
> First, that queue was intended for more than just SIGCHLD.
>
> And second, depending on the OS, nested signals can or cannot be
> possible, so we need to take that into consideration.
I understand now, I think. Thank you.
> > One last suggestion: how about blocking those signals for most of Emacs' lifetime, only unblocking them in maybe_quit or at similar points? That would allow us to keep the existing signal handlers and make them safe...
>
> IMO, this would be the opposite of what we should do. We should have
> these signals blocked for as little time as possible, because
> otherwise the features built on them will be much less useful. For
> example, SIGUSR1/2 are a means of forcing Emacs out of some infinite
> loop which is otherwise uninterruptible -- if we let these signals be
> unblocked only in maybe_quit, we will have lost this useful feature.
Thanks for making that clear. That is a very useful feature and I would like to keep it. I'm also quite fond of the hourglass cursor :-)
> Which is why I suggested to block the signals before calling MPS and
> unblock them immediately when we return from an MPS call. All of
> these calls are in igc.c, so the job of adding these blocks, while
> mundane and boring, is not impossible.
And it adds two syscalls to what should be a very fast operation. I'm not convinced it's necessary.
> But if people who have time to work on that disagree, I have no means
> of making them do what they don't agree with.
>
> > I still think this is a simple oversight on the part of MPS, FWIW. You shouldn't allow other signals when handling SIGSEGV, or at least give the client program an option to specify a signal mask.
>
> That's not the problem, AFAIU. The problem is that a signal handler
> which accesses Lisp data or the state of the Lisp machine could
> trigger an MPS call, which will try taking the arena lock, and that
> cannot be nested, by MPS design. And our handlers do access the Lisp
> machine, albeit cautiously and as little as necessary. So when the
> signal happens in the middle of an MPS call which already took the
> arena lock, we cannot safely access our data.
I've tried quite hard to make this happen, but I didn't manage it. It seems that whenever MPS puts up a protection barrier for existing allocated memory, the arena lock has already been released. As signal handlers cannot allocate memory directly, there's no deadlock, either.
I don't understand MPS as well as you apparently do, so could you help me and tell where to put a kill(getpid(), SIGWHATEVER) with an appropriate signal handler which will cause a crash (without, in the signal handler, allocating memory)?
I'm seriously tempted to suggest that until we can produce such a crash, we can work on the assumption that blocking signals while handling SIGSEGV is enough, but, again, I don't fully understand MPS and its complicated locking scheme.
To expand a little on what I'm doing:
* install a handler for SIGUSR2 which dereferences a pointer stored in a global variable (and remove the old SIGUSR2 handler)
* modify MPS's locking functions to kill(getpid(), SIGUSR2) right after acquiring the lock
* in gdb, wait for a SIGSEGV to find a protected address/segment. Store that in the pointer variable.
* there should now be a crash when the SIGUSR2 handler runs and memory protection for the pointer is in effect
* no crashes observed so far.
Pip
next prev parent reply other threads:[~2024-07-02 7:55 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-29 19:12 MPS: a random backtrace while toying with gdb Ihor Radchenko
2024-06-29 19:19 ` Pip Cet
2024-06-29 21:46 ` Gerd Möllmann
2024-06-30 4:55 ` Eli Zaretskii
2024-06-30 5:33 ` Gerd Möllmann
2024-06-30 6:16 ` Eli Zaretskii
2024-06-30 6:43 ` Gerd Möllmann
2024-06-30 8:52 ` Eli Zaretskii
2024-06-30 9:43 ` Gerd Möllmann
2024-06-30 10:05 ` Eli Zaretskii
2024-06-30 11:20 ` Gerd Möllmann
2024-06-30 12:16 ` Eli Zaretskii
2024-06-30 12:43 ` Gerd Möllmann
2024-06-30 9:36 ` Helmut Eller
2024-06-30 10:00 ` Eli Zaretskii
2024-06-30 10:24 ` Helmut Eller
2024-06-30 10:43 ` Eli Zaretskii
2024-06-30 18:42 ` Helmut Eller
2024-06-30 18:59 ` Gerd Möllmann
2024-06-30 19:25 ` Pip Cet
2024-06-30 19:49 ` Ihor Radchenko
2024-06-30 20:09 ` Eli Zaretskii
2024-06-30 20:32 ` Pip Cet
2024-07-01 11:07 ` Eli Zaretskii
2024-07-01 17:27 ` Pip Cet
2024-07-01 17:42 ` Ihor Radchenko
2024-07-01 18:08 ` Eli Zaretskii
2024-07-02 7:55 ` Pip Cet [this message]
2024-07-02 13:10 ` Eli Zaretskii
2024-07-02 14:24 ` Pip Cet
2024-07-02 14:57 ` Eli Zaretskii
2024-07-02 17:06 ` Pip Cet
2024-07-03 11:31 ` Pip Cet
2024-07-03 11:50 ` Eli Zaretskii
2024-07-03 14:35 ` Pip Cet
2024-07-03 15:41 ` Eli Zaretskii
2024-07-01 2:33 ` Eli Zaretskii
2024-07-01 6:05 ` Helmut Eller
2024-06-30 19:58 ` Eli Zaretskii
2024-06-30 21:08 ` Ihor Radchenko
2024-07-01 2:35 ` Eli Zaretskii
2024-07-01 11:13 ` Eli Zaretskii
2024-07-01 11:47 ` Ihor Radchenko
2024-07-01 12:33 ` Eli Zaretskii
2024-07-01 17:17 ` Ihor Radchenko
2024-07-01 17:44 ` Eli Zaretskii
2024-07-01 18:01 ` Ihor Radchenko
2024-07-01 18:16 ` Eli Zaretskii
2024-07-01 18:24 ` Ihor Radchenko
2024-07-01 18:31 ` Eli Zaretskii
2024-07-01 18:51 ` Ihor Radchenko
2024-07-01 19:05 ` Eli Zaretskii
2024-07-01 19:34 ` Gerd Möllmann
2024-07-01 20:00 ` Ihor Radchenko
2024-07-02 4:33 ` Gerd Möllmann
2024-07-02 7:05 ` Ihor Radchenko
2024-07-02 7:06 ` Gerd Möllmann
2024-07-01 18:19 ` Gerd Möllmann
2024-07-01 18:23 ` Eli Zaretskii
2024-06-30 11:07 ` Gerd Möllmann
2024-06-30 11:06 ` Gerd Möllmann
2024-06-30 11:05 ` Gerd Möllmann
2024-06-30 9:59 ` Pip Cet
2024-06-30 10:09 ` Eli Zaretskii
2024-06-30 10:16 ` Pip Cet
2024-06-30 10:34 ` Eli Zaretskii
2024-06-30 13:06 ` Pip Cet
2024-06-30 11:10 ` Gerd Möllmann
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CT5MbHCspJZE5id507qGzJXm0wcGmmPg7GX4fDVsC1C4ZDbXMceItHgG9ZZO8Rra9CJDDw8HsClcrkL7kMqu7Kty1qFQ6sgdnhohdALWIbQ=@protonmail.com' \
--to=pipcet@protonmail.com \
--cc=eliz@gnu.org \
--cc=eller.helmut@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=gerd.moellmann@gmail.com \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).