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: Aaron Jensen <aaronjensen <at> gmail.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 60220 <at> debbugs.gnu.org
Subject: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs
Date: Wed, 21 Dec 2022 14:22:06 +0200

> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Tue, 20 Dec 2022 22:47:46 -0500
> Cc: 60220 <at> 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.

Previous Next

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