Re: igc, macOS avoiding signals

[Pip Cet]

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

> Pip Cet <pipcet@protonmail.com> writes:
>
>> Pip Cet <pipcet@protonmail.com> writes:
>>
>>> "Helmut Eller" <eller.helmut@gmail.com> writes:
>>>>> I find that difficult to understand. But it may be just a
>>>>> statistical phenomenon. Maybe filling up an APs memory is so fast so
>>>>> that the probability of a signal hitting while owning the mutex is close
>>>>> to zero, or something.
>>>>
>>>> Very few of Emacs' signal handlers actually touch a barrier.  I've also
>>>
>>> Indeed.  These crashes are rare in typical usage, which doesn't mean we
>>> should delay fixing them until Emacs is "unstable enough".  It already
>>> is, IMHO, because we take that approach too frequently.
>>>
>>>> not seen any reproducable receipes for the "signal issues" that the igc
>>>> branch supposedly has.
>>>
>>> Removing the SIGPROF protection code should allow Ihor's recipe to crash
>>> again.
>>
>> Confirmed.  Here's the recipe (which, yes, you have already seen):
>>
>> https://lists.gnu.org/archive/html/emacs-devel/2024-06/msg00560.html
>>
>> Make igc_busy_p () return false (as we could do if the "supposed" signal
>> issue weren't real), immediate crash.
>>
>> Pip
>
> 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?

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