Re: MPS: a random backtrace while toying with gdb

[Ihor Radchenko]

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_. Fcons requests MPS to allocate memory for a new
cons, MPS does it, not super quickly, and blocks the whole arena
(all the lisp memory) in the process. At the same time, signal arrives,
and we try to access the (blocked) arena.

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).

I do not see why the same cannot happen with vanilla malloc, unless, of
course, it blocks memory much more granularly, guaranteeing that live
objects are always reachable.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>