GNU bug report logs - #60220
29.0.60; macOS 13.1 crash shortly after starting Emacs

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 60220 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
Subject: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
Date: Thu, 22 Dec 2022 10:18:09 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Thu, 22 Dec 2022 06:36:43 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 60220 <at> debbugs.gnu.org
> 
> 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. 

Yes, I think our implementation of restart-emacs might be too naïve.

Paul, could you perhaps audit the code which implements restart-emacs,
and see if we need to make it safer, in particular wrt signals and
*.eln files loaded via dynlib.  Note that on Posix platforms we
currently load *.eln files with RTLD_LAZY and without RTLD_GLOBAL --
is this of any significance for "restarting" Emacs that was built with
native-compilation enabled and has *.eln files loaded?  Maybe we need
to unload the *.eln before calling execvp?

Or maybe we should consider re-implementing restart-emacs in some
different way, to avoid these problems?

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.