bug#58956: mark_object, mark_objects(?) crash

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Sorry I missed those traces.  Okay so for both cases if libgccjit is not
involved the behaviour of Emacs here is just the plain one and should
not be related to native compilation.  It's just that native compilation
makes it more likely to be identify this condition.

>> 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?

To me yes.

> 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?

I think we have no special handling for this case, so yeah we might
leave some traces of the compilation.  Other than the .eln we should
also remove the lisp file we write to be loaded by the async compilation
process.  I'm not sure where and how would be best to handle all of this
tho.

Best Regards

  Andrea