bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs

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

If I remember that correctly, installed signal handlers don’t survive process replacement. The man pages for execve and sigaction should tell. 

If that’s the case the new process has a default handler for SIGALRM which terminates. 

But please check the man pages if that’s true. 

Sent from my iPhone

> On 21. Dec 2022, at 13:22, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> 
>> 
>> From: Aaron Jensen <aaronjensen@gmail.com>
>> Date: Tue, 20 Dec 2022 22:47:46 -0500
>> Cc: 60220@debbugs.gnu.org
>> 
>>>> Process 19414 exited with status = 14 (0x0000000e) Terminated due to signal 14
>>> 
>>> What is "signal 14" on macOS?
>> 
>> This is all I could find:
>> 
>>     14    SIGALRM      terminate process    real-time timer expired
>> 
>> I'm able to reproduce the above without native compilation as well.
>> This particular thing only happens when in a lldb and doesn't affect
>> me in practice.
> 
> The only place we use SIGALRM in Emacs is in interval timesr (see
> atimer.c), which are used for stuff like hour-glass cursor and input
> polling.
> 
> Once again, this might mean we are not cleaning up the process state
> before calling execvp.  But that is just a speculation.
> 
>>> Anyway, look at the code: we restart by calling execvp.  You or
>>> someone who knowns macOS internals should take a look at what that
>>> means for shared libraries which were loaded by the program that calls
>>> execvp -- what happens with those libraries in the execvp'ed process.
>>> I'm guessing that they are not being unloaded and re-loaded by the new
>>> process, or something to that effect.
>>> 
>>> Or maybe the way we load the *.eln files causes this, triggered by
>>> 'execvp'?
>> 
>> This is out of my depth.
> 
> Mine as well.  Gerd, any ideas or hints?
> 
>> I did a tiny bit of digging and didn't find anything.
> 
> Likewise.
> 
>>> Can you try running for a while Emacs built without native compilation
>>> and restarting it?  That could tell us whether the *.eln files are the
>>> problem.
>> 
>> I wasn't able to reproduce it w/o native compilation. I'm going to try
>> running w/ native compilation for a while *without* doing any restarts
>> and see if I can get it to crash. I've seen crashes take an hour+
>> after a restart (though most happen w/in 30 seconds). I can't say
>> definitively that all crashes have happened in a restarted process.
> 
> OK, thanks.