> Date: Thu, 3 Nov 2022 11:13:08 +0100 > From: Vincent Lefevre <vinc...@vinc17.net> > Cc: spwhit...@spwhitton.name, 58...@debbugs.gnu.org, > 1017...@bugs.debian.org > > On 2022-11-03 08:47:06 +0200, Eli Zaretskii wrote: > > > On 2022-11-02 14:24:51 +0200, Eli Zaretskii wrote: > > > > Signal 1 is SIGHUP, AFAIU. Why should Emacs receive SIGHUP in the > > > > middle of GC, I have no idea. Maybe ask the user what was he doing at > > > > that time. E.g., could that be a remote Emacs session? > > > > > > No, it is on my local machine. > > > > So how come Emacs gets a SIGHUP? This is the crucial detail that is > > missing here. Basically, if SIGHUP is delivered to Emacs, Emacs is > > supposed to die a violent death. > > I suspect the SIGHUP comes from Emacs itself. According to strace > output, the only processes started by Emacs are "/usr/bin/emacs" > (there are many of them). I don't see what other process could be > aware of the situation. Unfortunately, I couldn't reproduce the > issue with strace (I suspect some race condition). > > > > I run emacs, and quit it immediately. The generation of the core dump > > > is almost 100% reproducible. Ditto with "emacs -nw". > > > > Wait, you mean the crash is during exiting Emacs? > > For this test, yes. In general, I don't know. > > > That could mean Emacs receives some input event when it's half-way > > through the shutdown process, and the input descriptor is already > > closed. > > Note that the process that crashes is not the Emacs I started, > but a subprocess run by Emacs itself, since it has arguments like > "-no-comp-spawn --batch -l /tmp/emacs-async-comp-url.el-FGov4z.el".
Andrea, could you please look into this? The SIGHUP could be because the parent process exits, but that shouldn't cause a crash in the sub-process that performs native compilation? Thanks.
