bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 46256@debbugs.gnu.org, andrewjmoreton@gmail.com
>> Date: Sun, 07 Mar 2021 18:53:50 +0000
>> 
>> > (I must say that the way the async compilations are run makes it hard
>> > to track down fatal errors, because I don't even have an easy way of
>> > knowing which .el file was being compiled when the crash happened.
>> > Any enhancements of the logging and the diagnostic messages to help in
>> > these matters will be very welcome.  E.g., how about introducing an
>> > intermediate log level that would just show the currently compiled .el
>> > file's name?)
>> 
>> Setting `comp-async-jobs-number' to 1 and looking into the
>> *Async-native-compile-log* what we are looking for in this case?
>
> Will try that next time.  But meanwhile, I got the same problem while
> rebuilding after your comp.c change.  This time I clearly saw that
> cc-mode.el is being compiled:
>
>   Dumping under the name emacs.pdmp
>   Dumping fingerprint: 
> 3869e2b5d74557015002c58022bce8f2e19ba06f1636f4182d7837703d6
>   22982
>   Dump complete
>   Byte counts: header=100 hot=7960440 discardable=158256 cold=4873352
>   Reloc counts: hot=501593 discardable=5154
>   Adding name emacs-28.0.50.22.exe
>   Adding name emacs-28.0.50.22.pdmp
>   cp -f emacs.pdmp bootstrap-emacs.pdmp
>   make[1]: Leaving directory `/d/gnu/git/emacs/native-comp/src'
>   make -C lisp all
>   make[1]: Entering directory `/d/gnu/git/emacs/native-comp/lisp'
>   make -C ../leim all EMACS="../src/emacs.exe"
>   make -C ../admin/grammars all EMACS="../../src/emacs.exe"
>   make[2]: Entering directory `/d/gnu/git/emacs/native-comp/admin/grammars'
>   make[2]: Nothing to be done for `all'.
>   make[2]: Leaving directory `/d/gnu/git/emacs/native-comp/admin/grammars'
>   make[2]: Entering directory `/d/gnu/git/emacs/native-comp/leim'
>   make[2]: Nothing to be done for `all'.
>   make[2]: Leaving directory `/d/gnu/git/emacs/native-comp/leim'
>   make[2]: Entering directory `/d/gnu/git/emacs/native-comp/lisp'
>   make[2]: Nothing to be done for `compile-targets'.
>   make[2]: Leaving directory `/d/gnu/git/emacs/native-comp/lisp'
>   make[2]: Entering directory `/d/gnu/git/emacs/native-comp/lisp'
>   make[2]: Nothing to be done for `compile-targets'.
>   make[2]: Leaving directory `/d/gnu/git/emacs/native-comp/lisp'
>   make[2]: Entering directory `/d/gnu/git/emacs/native-comp/lisp'
>     ELC      progmodes/cc-mode.elc
>
>   comp.h:70: Emacs fatal error: assertion failed: NATIVE_COMP_UNITP (a)
>
> Attaching a debugger produces the backtrace shown below.  I will leave
> this process captured in the debugger, in case you want me to look at
> some variables and report their values.
>
>   Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
>   [Switching to Thread 5500.0x114c]
>   0x7c90120f in ntdll!DbgBreakPoint () from C:\WINDOWS\system32\ntdll.dll
>   (gdb) bt
>   #0  0x7c90120f in ntdll!DbgBreakPoint () from C:\WINDOWS\system32\ntdll.dll
>   #1  0x0135a63b in emacs_abort () at w32fns.c:10914
>   #2  0x0115c637 in terminate_due_to_signal (sig=22, 
> backtrace_limit=2147483647)
>       at emacs.c:417
>   #3  0x0121c026 in die (msg=0x1782af2 <targets+1266> "NATIVE_COMP_UNITP (a)",
>       file=0x1782aeb <targets+1259> "comp.h", line=70) at alloc.c:7452
>   #4  0x012cf582 in XNATIVE_COMP_UNIT (a=XIL(0x6f04860091b9000)) at comp.h:70
>   #5  0x012df324 in load_comp_unit (comp_u=0x6f33918, loading_dump=false,
>       late_load=false) at comp.c:4821
>   #6  0x012e0c55 in Fnative_elisp_load (filename=XIL(0x80000000092db190),
>       late_load=XIL(0)) at comp.c:5122

What I think is going on here:

The same .eln file is loaded two times, we detect that and try to reuse
the same compilation unit (the Lisp object) instead of a new one.

We keep a pointer to the compilation unit representing the .eln file in
each .eln.  Here we read it and we have it into 'saved_cu', we try to
dereference it and extract the CU with XNATIVE_COMP_UNIT but something
goes wrong.

This object might have been GC'ed for some reason and we might be
looking at the same GC issue I've seen on 32bit wide-int (my guess).
*If* this is the case the question is: why is the CU GC'ed?

Thanks

  Andrea