Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com,
>  emacs-devel@gnu.org
> Date: Mon, 01 Jul 2024 18:51:13 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I was mostly asking about technical implementation details of how malloc
> >> is preventing signals from being handled while it is doing its
> >> job.
> >
> > It doesn't.  It's the responsibility of the signal handlers not to
> > re-enter malloc.
> >
> > We cannot do the same with MPS, because MPS can kick in outside of our
> > control -- for example, if accessing some Lisp object hits the
> > barrier.  So we have no idea when MPS will take the arena lock, and
> > this cannot prevent recursive locks, except by preventing our code
> > which touches Lisp data from running when MPS is active because we
> > called it.
> 
> AFAIU, the situation discussed in this thread is different - MPS kicks
> in _in our control_.

Yes.  But we had other backtraces where what I described happened.  So
the situation we need to solve is more general.

> Note that our SIGCHLD signal handler itself does not re-enter malloc
> (igc_malloc in our case). It just tries to access the memory arena that
> is in transient state (in process of allocation).

Yes.  And any other signal handler that does something except raising
a flag will do something similar.

> I do not see why the same cannot happen with vanilla malloc

Because vanilla malloc doesn't move objects in memory, and this
doesn't need to lock the arena.  It only needs to lock the data
structure it itself uses for managing the memory, so if the handler
doesn't re-enter malloc, it will never cause any trouble to vanilla
malloc.