Re: MPS: a random backtrace while toying with gdb

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Indeed
>> 
>>   #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
>> 
>> Someone has an idea what to do with that?
>
> Call sigblock at the beginning of dflt_scan (and friends) and
> sigunblock before it returns?

Yuk.

> Are there any guidance in the MPS docs for handling such signals in
> these situations?  If not, can we ask them for guidance?  It is
> unrealistic to expect any real-life program to do nothing in signal
> handlers except setting flags.  And even flags could be subject to MPS
> moving GC, at least in some cases.  So there must be some way of
> dealing with that in a safe way.

It's Emacs' fault. MPS cannot reasonably be expected to assume that a
client program uses MPS managed memory in a signal handler. My 2 cents.

>
>> And maybe how to reproduce?
>
> Run for enough time with subprocesses that start and terminate, I
> guess?

Just remembered that I won't be able to reproduce this anyway an macOS,
where barriers don't use signals.