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

[Gerd Möllmann]

I was more thinking of something like this:

A SIGALRM handler is installed in the original process. SIGALRM continues to be 
delivered to the new process after execve but the signal handler is now the 
default handler which terminates the process. 

The man pages I mentioned should say somewhere if that’s plausible. It looks to 
me like that could be what’s happening. But it’s a guess. 

If it is that, one would need to arrange for SIGALRM to be ignored before 
execve and reinitialize a timers in the new process. Or something like that. 

Sent from my iPhone

> On 22. Dec 2022, at 06:12, Aaron Jensen <aaronjensen@gmail.com> wrote:
> 
> On Thu, Dec 22, 2022 at 12:09 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>> 
>>> On Wed, Dec 21, 2022 at 8:29 AM Gerd Möllmann <gerd.moellmann@gmail.com> 
>>> wrote:
>>> 
>>> If I remember that correctly, installed signal handlers don’t survive 
>>> process replacement. The man pages for execve and sigaction should tell.
>> 
>> If I'm reading this correctly, that is the case:
>> 
>> Signals set to be ignored in the calling process are set to be ignored
>> in the new process. Signals which are set to be caught in the calling
>> process image are set to default action in the new process image.
>> Blocked
>> signals remain blocked regardless of changes to the signal action.
>> The signal stack is reset to be undefined (see sigaction(2) for more
>> information).
>> 
>> 
>> 
>> I have not had a crash today. I have also not restarted Emacs via 
>> restart-emacs.
> 
> 
> Is this of any relevance?
> 
> File descriptors open in the calling process image remain open in the
> new process image, except for those for which the close-on-exec flag
> is set (see close(2) and fcntl(2)).  Descriptors that remain open are
> unaffected by execve().
> 
> Aaron