bug#57267: 28.1; emacs crashes when loading too many images

[Gerd Möllmann]

james@jojojames.com writes:

> This is what I get with the Emacs.app binary: (upon startup)
>
> src/ $ lldb ../nextstep/Emacs.app/Contents/MacOS/Emacs 
> Emacs debugging support has been installed.
> (lldb) target create "../nextstep/Emacs.app/Contents/MacOS/Emacs"
> Current executable set to 
> '/Users/james/Code/emacs/nextstep/Emacs.app/Contents/MacOS/Emacs' (x86_64).
> (lldb) r
> Process 5114 launched: 
> '/Users/james/Code/emacs/nextstep/Emacs.app/Contents/MacOS/Emacs' (x86_64)
> Warning: Lisp directory 'Contents/Resources/lisp': No such file or
> directory

Ok, that's a relative path, so I think it expects to be started with
current directory being nextstep/Emacs.app.

> =================================================================
> ==5114==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 
> 0x7ffeefbfe76e at pc 0x000102ee74d3 bp 0x7ffeefbfd9b0 sp
> 0x7ffeefbfd178
> WRITE of size 25 at 0x7ffeefbfe76e thread T0
>     #0 0x102ee74d2 in __asan_memcpy+0x262 
> (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x424d2)
>     #1 0x1008b3733 in doprnt doprnt.c:456
>     #2 0x1008b5351 in esprintf doprnt.c:551
>     #3 0x1007d2a43 in dir_warning lread.c:5385
>     #4 0x1007d1b53 in load_path_check lread.c:5145
>     #5 0x1007d1631 in init_lread lread.c:5338
>     #6 0x1004911cd in main emacs.c:2151
>     #7 0x7fff204bff3c in start+0x0 (libdyld.dylib:x86_64+0x15f3c)
>
> Address 0x7ffeefbfe76e is located in stack of thread T0 at offset 718 in frame
>     #0 0x1008b512f in esprintf doprnt.c:547
>
>   This frame has 1 object(s):
>     [32, 56) 'ap' (line 549) <== Memory access at offset 718 overflows this 
> variable
> HINT: this may be a false positive if your program uses some custom stack 
> unwind mechanism, swapcontext or vfork
>       (longjmp and C++ exceptions *are* supported)
> SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow 
> (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x424d2) in __asan_memcpy+0x262
> Shadow bytes around the buggy address:
>   0x1fffddf7fc90: 00 00 00 00 f1 f1 f1 f1 00 00 00 f3 f3 f3 f3 f3
>   0x1fffddf7fca0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1fffddf7fcb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1fffddf7fcc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1fffddf7fcd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x1fffddf7fce0: ca ca ca ca 00 00 00 00 00 00 00 00 00[06]cb cb
>   0x1fffddf7fcf0: cb cb cb cb f1 f1 f1 f1 00 00 00 00 f2 f2 f2 f2
>   0x1fffddf7fd00: 00 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1fffddf7fd10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1fffddf7fd20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1fffddf7fd30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

And that's how a real ASAN error looks like.  ASAN has detected a
buffer-overflow in doprnt.  I'll try to debug this later if I don't
forget.

Thanks for the report!