Re: MPS: a random backtrace while toying with gdb

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Ihor Radchenko <yantar92@posteo.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> 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?
>
> Nope. AFAIU, the problem we are facing is not when MPS GC runs, but when
> we query MPS to allocate memory in the managed arena.

AFAIU, there are 2 scenarios:

1. The client allocates memory from MPS, via an allocation point. APs
normally allocate from a block they reserve, which is why this is
usually surprisingly fast. More must done when the reserved block is
used up. Then, MPS scans mempory, tries to free some, and so on. This
happens synchronously in the client thread.

2. MPS concurrently does incrementally work. It scans some part of the
meoory, for example, and functions of the object format are called
(those in igc.c). This happens in the MPS thread.

>> 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.
>
> I do not mean calling malloc. I mean, what happens if a signal arrives
> _while_ malloc is still in the process of allocating data?

One would have to consult the malloc implementation. Portably, it's not
safe to call malloc in a signal handler.