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

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

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