Re: MPS: a random backtrace while toying with gdb

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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?

Not a crime, but we are using a lib that we know uses barriers and
functions of which get invoked when we hit such a barrier. We can't just
ignore that.

>> 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?

I can't tell you exactly how MPS does this on macOS because I'm refusing
to study their code, where possible at least. Fact is that barrier hits
on macOS don't result in a signal, but are handled as Mach exceptions.
Maybe their design docs have something explaining this, don't know.