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 17:17:06 +0000
> 
> I looked a bit into mps sources and what I observe is
> mps_ap_fill -> ArenaEnter -> ArenaEnterLock -> LockClaim.
> This is active for the duration of our dflt_scan.
> Nothing can access the MPS arena and when something tries to, we get
> assertion failure.

Yes.

> It looks like we can test whether the Arena is locked via
> 
> /* mps_arena_busy -- is the arena part way through an operation? */
> 
> mps_bool_t mps_arena_busy(mps_arena_t arena)
> 
> Although it does not help with the underlying problem with signal
> arriving while we are in the process of allocating a new object in the
> pool.

Blocking signals whose handlers access the data of the Lisp machine
will prevent that.

> I am wondering what happens in the same situation when using normal
> malloc. (Or may it never happen when using normal malloc?)

You mean, when the current GC runs?  Signal handlers are free to
access Lisp data even if the signal happens while we are in GC, they
just need to be careful to mask off the mark bit (see, for example,
the commentary to handle_child_signal).

If you really mean malloc, then there usually is not problem because
signal handlers cannot safely call malloc.  And if malloc causes GC,
see above.