From: Eli Zaretskii <eliz@gnu.org>
To: "Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: pipcet@protonmail.com, yantar92@posteo.net, emacs-devel@gnu.org,
eller.helmut@gmail.com
Subject: Re: MPS: a random backtrace while toying with gdb
Date: Sun, 30 Jun 2024 11:52:52 +0300 [thread overview]
Message-ID: <86r0cehkwr.fsf@gnu.org> (raw)
In-Reply-To: <m2cynzkk21.fsf@pro2.fritz.box> (message from Gerd Möllmann on Sun, 30 Jun 2024 08:43:02 +0200)
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com, yantar92@posteo.net, emacs-devel@gnu.org,
> eller.helmut@gmail.com
> Date: Sun, 30 Jun 2024 08:43:02 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Why "yuck"? That's a valid solution, IMO, especially if there are no
> > better ones. I'm talking about blocking only a small number of
> > signals: SIGCHLD, SIGPROF, SIGALRM, and maybe also SIGIO and SIGINT.
> > (We should also consider SIGUSR1 and SIGUSR2.)
>
> I find that really ugly. Of course, should there be no other solution on
> some platforms, we can try that. It's not needed for macOS, for example.
We should only block signals where that is necessary, of course.
> >> > Are there any guidance in the MPS docs for handling such signals in
> >> > these situations? If not, can we ask them for guidance? It is
> >> > unrealistic to expect any real-life program to do nothing in signal
> >> > handlers except setting flags. And even flags could be subject to MPS
> >> > moving GC, at least in some cases. So there must be some way of
> >> > dealing with that in a safe way.
> >>
> >> It's Emacs' fault. MPS cannot reasonably be expected to assume that a
> >> client program uses MPS managed memory in a signal handler. My 2 cents.
> >
> > That's unreasonable, IMNSHO. Programs manage memory for various
> > purposes, and nothing in principle should prevent a program from
> > accessing MPS-managed memory from a signal handler.
>
> I disagree.
>
> > Are you saying that a program that manages _all_ of its heap-allocated
> > memory via MPS cannot also handle signals in a safe way?
>
> The program can do both, but only if the signal handler behaves. There
> is not much a signal handler is allowed to do. Portably it can do almost
> nothing. But even non-portably, it's never safe to call non-reentrant
> code. On Linux, there is a list of async-signal-safe functions one can
> call in a signal handler, others cannot be used.
Which unsafe function did we call in this case, though? AFAICT, we
simply accessed memory that happens to be behind the barrier:
#9 0x00007ffff3048050 in <signal handler called> () at /lib64/libc.so.6
#10 0x0000555555827385 in PSEUDOVECTORP (a=XIL(0x7fffeb90875d), code=9) at /home/yantar92/Git/emacs/src/lisp.h:1105
#11 PROCESSP (a=XIL(0x7fffeb90875d)) at /home/yantar92/Git/emacs/src/process.h:212
#12 XPROCESS (a=XIL(0x7fffeb90875d)) at /home/yantar92/Git/emacs/src/process.h:224
#13 handle_child_signal (sig=sig@entry=17) at process.c:7660
Line 7660 of process.c is this:
struct Lisp_Process *p = XPROCESS (proc);
What "crime" did we commit here?
> I don't expect MPS to be async-signal-safe. I find that unreasonble.
> Why would it be? Emacs's isn't either. Almost nothing is.
See above: I'm not sure this is about async-signal-safety.
> >> Just remembered that I won't be able to reproduce this anyway an macOS,
> >> where barriers don't use signals.
> >
> > AFAIU, this scenario is not necessarily related to barrier-related
> > signals. SIGCHLD caused us to access MPS-managed memory, which
> > violated some assertion in MPS, because the arena lock was already
> > taken.
>
> I would have to see an example where no barrier is involved. It is in
> this case. MPS is doing work, therefore holds the lock, receives SIGxy
> which it let's the client handle. The client hits a barrier, which
> invokes MPS's signal handler, which tries to acquire the lock which is
> already taken.
Wouldn't the equivalent mechanism used on macOS also want to acquire
the arena lock in this case? If not, what will it do?
next prev parent reply other threads:[~2024-06-30 8:52 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 [this message]
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
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=86r0cehkwr.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=eller.helmut@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=gerd.moellmann@gmail.com \
--cc=pipcet@protonmail.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).