Subject: Re: bug#58956: mark_object, mark_objects(?) crash

From: Vincent Lefevre <[email-masked]>
Date: Thu, 3 Nov 2022 11:13:08 +0100

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".
However, it also happened that the Emacs I started immediately
crashed (this occurred only once, though).

-- 
Vincent Lefèvre <[email-masked]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)