Subject: bug#66416: GDB output from new crash

From: Eli Zaretskii <[email-masked]>
Date: Sat, 14 Oct 2023 18:40:53 +0300

> From: Yuchen Guo <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>,  [email-masked]
> Date: Sat, 14 Oct 2023 14:23:44 +0000
> 
> Po Lu <[email-masked]> writes:
> 
> > Is it possible to build Emacs with -fsanitize=address?
> 
> Yes, I've added this argument to CFLAGS and am rebuilding now.
> 
> Of note, I rebuilt pgtk Emacs without native compilation in order to
> save time. Emacs has not yet crashed since that rebuild.  Don't know if
> this might be related.
> 
> > This is further expounded upon in the GCC manual, and IME generally
> > proves fruitful for such spasmodic bugs, since you can run Emacs with
> > address sanitization enabled for extended periods of time as your
> > "daily driver" (vis-a-vis tools such as Valgrind, which incur a
> > prohibitive performance penalty).
> 
> I'm currently starting Emacs server with systemd and hoping it would
> crash sooner, but not when I'm writing assignments. ;-)
> 
> Update: the rebuild failed with the following output:
> 
>   ELC      textmodes/less-css-mode.elc
>   ELC      textmodes/makeinfo.elc
>   ELC      textmodes/mhtml-mode.elc
>   ELC      textmodes/nroff-mode.elc
>   ELC      textmodes/page-ext.elc
>   ELC      textmodes/picture.elc
> 
> =================================================================
> ==14797==ERROR: LeakSanitizer: detected memory leaks
> 
> Indirect leak of 1528 byte(s) in 2 object(s) allocated from:
>     #0 0x7ffff79d7de7 in __interceptor_calloc (/nix/store/xq05361kqwzcdamcsxr4gzg8ksxrb8sg-gcc-12.3.0-lib/lib/libasan.so.8+0xbbde7)
>     #1 0x74ddda in lmalloc /build/source/src/alloc.c:1365
> 
> Indirect leak of 1392 byte(s) in 8 object(s) allocated from:
>     #0 0x7ffff79d83ff in __interceptor_malloc (/nix/store/xq05361kqwzcdamcsxr4gzg8ksxrb8sg-gcc-12.3.0-lib/lib/libasan.so.8+0xbc3ff)
>     #1 0x74de07 in lmalloc /build/source/src/alloc.c:1365
> 
> SUMMARY: AddressSanitizer: 2920 byte(s) leaked in 10 allocation(s).
> make[3]: *** [Makefile:332: progmodes/typescript-ts-mode.elc] Error 1
> make[3]: *** Waiting for unfinished jobs....
> 
> =================================================================
> ==14881==ERROR: LeakSanitizer: detected memory leaks
> 
> Indirect leak of 1528 byte(s) in 2 object(s) allocated from:
>     #0 0x7ffff79d7de7 in __interceptor_calloc (/nix/store/xq05361kqwzcdamcsxr4gzg8ksxrb8sg-gcc-12.3.0-lib/lib/libasan.so.8+0xbbde7)
>     #1 0x74ddda in lmalloc /build/source/src/alloc.c:1365
> 
> Indirect leak of 1392 byte(s) in 8 object(s) allocated from:
>     #0 0x7ffff79d83ff in __interceptor_malloc (/nix/store/xq05361kqwzcdamcsxr4gzg8ksxrb8sg-gcc-12.3.0-lib/lib/libasan.so.8+0xbc3ff)
>     #1 0x74de07 in lmalloc /build/source/src/alloc.c:1365
> 
> SUMMARY: AddressSanitizer: 2920 byte(s) leaked in 10 allocation(s).
> make[3]: *** [Makefile:332: textmodes/mhtml-mode.elc] Error 1
> make[3]: Leaving directory '/build/source/lisp'
> make[2]: *** [Makefile:366: compile-main] Error 2

I think it is best to suppress memory-leak testing at this stage,
since the problems we are investigating cannot be caused by leaks (if
these leaks are real leaks at all).