Re: igc, macOS avoiding signals

[Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Pip Cet <pipcet@protonmail.com> writes:
>
>>> With
>>>
>>>   modified   src/profiler.c
>>>   @@ -347,7 +347,7 @@ record_backtrace (struct profiler_log *plog, EMACS_INT count)
>>>    add_sample (struct profiler_log *plog, EMACS_INT count)
>>>    {
>>>    #ifdef HAVE_MPS
>>>   -  if (igc_busy_p ())
>>>   +  if (false)
>>>    #else
>>>      if (EQ (backtrace_top_function (), QAutomatic_GC)) /* bug#60237 */
>>>    #endif
>>
>> This is after removing gc_signal_handler_can_run, right?
>
> Right. And meanwhile it also survived the same parsing 100 times in a
> loop with profiling on around it.

Yes, without the SIGSEGV-alloc-SIGSEGV case, it becomes less likely to
hit a memory barrier.  But the alloc-SIGPROF-SIGSEGV case is real, we've
seen backtraces for it.

>> Even if, in addition, I block signals in the SIGSEGV handler, I see
>> crashes here, FWIW, but not quite every time that recipe is run.  It
>> seems to work even less reliably when rr is in use (and then I realized
>> I was running an optimized build so the trace was useless, sigh).
>>
>> I'd still like to see at least one crash on macOS, but there's nothing
>> I'm aware of that would prevent such crashes, only make them (maybe
>> much) less likely.  For starters, fewer pages so fewer barriers :-)
>>
>> Pip
>
> Me too, but I agree with you. It should eventually freeze, there's
> nothing preventing it that I could point to.

Or produce invalid data, which seems more likely: if we're scanning the
segment, the memory barrier won't be in place, but the contents will be
invalid, pointing to objects which we already decided to move (IOW, if
my double-mapping idea were in place, it'd be easier to catch these
bugs).  A crash is better than derefing random pointers pointing to the
(new) young generation when the object has been moved.

(I'm running into separate rr bugs on both systems I'm testing this on,
so we'll just have to assume that's what behind those crashes, at least
sometimes).

Does adding mps_message_poll (global_igc->arena) in the signal handler
produce a crash/deadlock for you?  Last thing I'm asking you to try
today, I promise :-)

Pip