GNU bug report logs -
#46256
[feature/native-comp] AOT eln files ignored if run from build tree
Previous Next
Full log
View this message in rfc822 format
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: 46256 <at> debbugs.gnu.org, andrewjmoreton <at> 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
This bug report was last modified 4 years and 130 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.