bug#58956: mark_object, mark_objects(?) crash

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Vincent Lefevre <vincent@vinc17.net>, spwhitton@spwhitton.name,
>         58956@debbugs.gnu.org, 1017711@bugs.debian.org
> Date: Thu, 03 Nov 2022 21:25:08 +0000
> 
> AFAIU the Emacs subprocess we use to compile should behave like a
> regular Emacs.

Basically, you are saying that if the sub-process that runs
async-compilation gets SIGHUP, it should abort and dump core, like a
normal Emacs session does, right?

The backtrace posted to the Debian bug tracker, here:

  
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1017711;filename=gdb.txt;msg=5

indicates that Emacs was in the middle of comp-copy-insn which was
called from comp-fwprop.  Then Emacs performed GC, and SIGHUP was
received during GC.  IOW, we were in our Lisp code, not in a libgccjit
code, when the signal arrived.

Another backtrace, posted here:

  
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1017711;filename=gdb.txt;msg=45

tells a somewhat different story: it doesn't show Emacs in the middle
of a native compilation, but just inside substitute-command-keys that
was called from command-line.

> Now, the only option that comes to my mind is that libgccjit (being
> strictly derived from the GCC codebase) might be registering a signal
> handler of some kind that alters the behaviour we expect.  But if this
> is the case we should find trace of it the strace, or we can use gdb
> setting a break point into 'signal' as well to check.
> 
> Indeed if this theory is true I think should be classified as a
> libgccjit bug.

I don't think it's true, see above.

Paul, can you help here, please?  We need to establish what is the
source of SIGHUP in these cases.  "These cases" mean, AFAIU, the
situations where Emacs launched an async subprocess to do native
compilation (which is another Emacs process in a --batch session), and
the parent Emacs session is terminated by the user before the async
compilation runs to completion.  Would the child Emacs process get
SIGHUP in this scenario?  If yes, then I think we should treat SIGHUP
differently in non-interactive invocations: instead of dumping core,
we should catch the signal and exit with a non-zero exit status.

Does this make sense?

Andrea, if we do the above as I suggest, is there any cleanup that we
need to do before exiting?  For example, what if the subprocess that
does the async compilation already started writing the .eln file when
the signal arrives?  What do we do today when the parent interactive
Emacs is terminated by the user?