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

From: [email-masked]
Date: Sat, 20 Aug 2022 12:29:34 -0400

> I don't quite understand.  I've seen to open errors in your log.  Are
you saying that these happen because you started Emacs from src this
time?  FWIW, I don't see differences when starting one or the other.

They were separate issues.

1. 2022-08-19 10:09:53.301888-0400 emacs[92880:17395371] fopen failed for data file: errno = 2 (No such file or directory) (hmnn?)

^ Just recently saw that in the logs after applying your suggestions.

2. Before (your suggestions), I did this to run emacs:

>> gdb/lldb ../nextstep/Emacs.app/Contents/MacOS/Emacs

After, it crashed on startup every time, so I did instead:

>> gdb/llb emacs

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
=================================================================
==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
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
2022-08-20 12:28:55.164360-0400 Emacs[5114:17882118] =================================================================
2022-08-20 12:28:55.164418-0400 Emacs[5114:17882118] ==5114==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffeefbfe76e at pc 0x000102ee74d3 bp 0x7ffeefbfd9b0 sp 0x7ffeefbfd178
2022-08-20 12:28:55.164429-0400 Emacs[5114:17882118] WRITE of size 25 at 0x7ffeefbfe76e thread T0
2022-08-20 12:28:55.164440-0400 Emacs[5114:17882118]     #0 0x102ee74d2 in __asan_memcpy+0x262 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x424d2)
2022-08-20 12:28:55.164450-0400 Emacs[5114:17882118]     #1 0x1008b3733 in doprnt doprnt.c:456
2022-08-20 12:28:55.164461-0400 Emacs[5114:17882118]     #2 0x1008b5351 in esprintf doprnt.c:551
2022-08-20 12:28:55.164483-0400 Emacs[5114:17882118]     #3 0x1007d2a43 in dir_warning lread.c:5385
2022-08-20 12:28:55.164507-0400 Emacs[5114:17882118]     #4 0x1007d1b53 in load_path_check lread.c:5145
2022-08-20 12:28:55.164519-0400 Emacs[5114:17882118]     #5 0x1007d1631 in init_lread lread.c:5338
2022-08-20 12:28:55.164529-0400 Emacs[5114:17882118]     #6 0x1004911cd in main emacs.c:2151
2022-08-20 12:28:55.164538-0400 Emacs[5114:17882118]     #7 0x7fff204bff3c in start+0x0 (libdyld.dylib:x86_64+0x15f3c)
2022-08-20 12:28:55.164549-0400 Emacs[5114:17882118] 
2022-08-20 12:28:55.164556-0400 Emacs[5114:17882118] Address 0x7ffeefbfe76e is located in stack of thread T0 at offset 718 in frame
2022-08-20 12:28:55.164565-0400 Emacs[5114:17882118]     #0 0x1008b512f in esprintf doprnt.c:547
2022-08-20 12:28:55.164576-0400 Emacs[5114:17882118] 
2022-08-20 12:28:55.164583-0400 Emacs[5114:17882118]   This frame has 1 object(s):
2022-08-20 12:28:55.164593-0400 Emacs[5114:17882118]     [32, 56) 'ap' (line 549) <== Memory access at offset 718 overflows this variable
2022-08-20 12:28:55.164603-0400 Emacs[5114:17882118] HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
2022-08-20 12:28:55.164614-0400 Emacs[5114:17882118]       (longjmp and C++ exceptions *are* supported)
2022-08-20 12:28:55.164624-0400 Emacs[5114:17882118] SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x424d2) in __asan_memcpy+0x262
2022-08-20 12:28:55.164635-0400 Emacs[5114:17882118] Shadow bytes around the buggy address:
2022-08-20 12:28:55.164644-0400 Emacs[5114:17882118]   0x1fffddf7fc90: 00 00 00 00 f1 f1 f1 f1 00 00 00 f3 f3 f3 f3 f3
2022-08-20 12:28:55.164654-0400 Emacs[5114:17882118]   0x1fffddf7fca0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2022-08-20 12:28:55.164664-0400 Emacs[5114:17882118]   0x1fffddf7fcb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2022-08-20 12:28:55.164673-0400 Emacs[5114:17882118]   0x1fffddf7fcc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2022-08-20 12:28:55.164682-0400 Emacs[5114:17882118]   0x1fffddf7fcd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2022-08-20 12:28:55.164693-0400 Emacs[5114:17882118] =>0x1fffddf7fce0: ca ca ca ca 00 00 00 00 00 00 00 00 00[06]cb cb
2022-08-20 12:28:55.164702-0400 Emacs[5114:17882118]   0x1fffddf7fcf0: cb cb cb cb f1 f1 f1 f1 00 00 00 00 f2 f2 f2 f2
2022-08-20 12:28:55.164721-0400 Emacs[5114:17882118]   0x1fffddf7fd00: 00 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
2022-08-20 12:28:55.164731-0400 Emacs[5114:17882118]   0x1fffddf7fd10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2022-08-20 12:28:55.164740-0400 Emacs[5114:17882118]   0x1fffddf7fd20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2022-08-20 12:28:55.164750-0400 Emacs[5114:17882118]   0x1fffddf7fd30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2022-08-20 12:28:55.164759-0400 Emacs[5114:17882118] Shadow byte legend (one shadow byte represents 8 application bytes):
2022-08-20 12:28:55.164768-0400 Emacs[5114:17882118]   Addressable:           00
2022-08-20 12:28:55.164779-0400 Emacs[5114:17882118]   Partially addressable: 01 02 03 04 05 06 07
2022-08-20 12:28:55.164799-0400 Emacs[5114:17882118]   Heap left redzone:       fa
2022-08-20 12:28:55.164818-0400 Emacs[5114:17882118]   Freed heap region:       fd
2022-08-20 12:28:55.164839-0400 Emacs[5114:17882118]   Stack left redzone:      f1
2022-08-20 12:28:55.164848-0400 Emacs[5114:17882118]   Stack mid redzone:       f2
2022-08-20 12:28:55.164856-0400 Emacs[5114:17882118]   Stack right redzone:     f3
2022-08-20 12:28:55.164864-0400 Emacs[5114:17882118]   Stack after return:      f5
2022-08-20 12:28:55.164871-0400 Emacs[5114:17882118]   Stack use after scope:   f8
2022-08-20 12:28:55.164878-0400 Emacs[5114:17882118]   Global redzone:          f9
2022-08-20 12:28:55.164885-0400 Emacs[5114:17882118]   Global init order:       f6
2022-08-20 12:28:55.164892-0400 Emacs[5114:17882118]   Poisoned by user:        f7
2022-08-20 12:28:55.164900-0400 Emacs[5114:17882118]   Container overflow:      fc
2022-08-20 12:28:55.164904-0400 Emacs[5114:17882118]   Array cookie:            ac
2022-08-20 12:28:55.164909-0400 Emacs[5114:17882118]   Intra object redzone:    bb
2022-08-20 12:28:55.164932-0400 Emacs[5114:17882118]   ASan internal:           fe
2022-08-20 12:28:55.165373-0400 Emacs[5114:17882118]   Left alloca redzone:     ca
2022-08-20 12:28:55.165387-0400 Emacs[5114:17882118]   Right alloca redzone:    cb
2022-08-20 12:28:55.165397-0400 Emacs[5114:17882118]   Shadow gap:              cc
==5114==ABORTING
(lldb) AddressSanitizer report breakpoint hit. Use 'thread info -s' to get extended information about the report.
Process 5114 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = AddressSanitizer detected: dynamic-stack-buffer-overflow
    frame #0: 0x0000000102ef1dc0 libclang_rt.asan_osx_dynamic.dylib`__asan::AsanDie()
libclang_rt.asan_osx_dynamic.dylib`__asan::AsanDie:
->  0x102ef1dc0 <+0>: pushq  %rbp
    0x102ef1dc1 <+1>: movq   %rsp, %rbp
    0x102ef1dc4 <+4>: pushq  %rbx
    0x102ef1dc5 <+5>: pushq  %rax
Target 0: (Emacs) stopped.
(lldb)  

> On Aug 20, 2022, at 12:23 PM, [email-masked] wrote:
> 
> > Could it be that one or more jpegs of yours is invalid in some way?
> Maybe you could check this with the 'jpeginfo' utitlity.  I've never
> used it myself, because I don't have a use for it, but from what I read,
> it might be able to detect at least some error cases.  Maybe it's worth
> trying.
> 
> Do you think that would lead to a crash every time? My crashes are very inconsistent.
> 
> > Another idea might be to try and install an external jpeg library
> (libjpeg I presume), and configure Emacs to use it.  Alas, this doesn't
> seem to work on my M1 Mac, but maybe it does on your x86_64 system.
> 
> Can you point me to some documentation for that?
> 
>> 
>> -------------------------------------------------------------------------------
>> 
>> 2022-08-19 10:09:53.301888-0400 emacs[92880:17395371] fopen failed for data file: errno = 2 (No such file or directory) (hmnn?)
>> 
>> This time I had to use:
>> 
>> /Users/james/Code/emacs/src/emacs
>> 
>> instead of $ lldb ../nextstep/Emacs.app/Contents/MacOS/Emacs (which crashed on startup)
>> 
> 
> I don't quite understand.  I've seen to open errors in your log.  Are
> you saying that these happen because you started Emacs from src this
> time?  FWIW, I don't see differences when starting one or the other.
> 
>> On Aug 20, 2022, at 2:34 AM, Gerd Möllmann <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Could it be that one or more jpegs of yours is invalid in some way?
>> Maybe you could check this with the 'jpeginfo' utitlity.  I've never
>> used it myself, because I don't have a use for it, but from what I read,
>> it might be able to detect at least some error cases.  Maybe it's worth
>> trying.
>> 
>> Another idea might be to try and install an external jpeg library
>> (libjpeg I presume), and configure Emacs to use it.  Alas, this doesn't
>> seem to work on my M1 Mac, but maybe it does on your x86_64 system.
>> 
>> In any case, this doesn't look like a problem to me that is caused by
>> Emacs.
>> 
>>> 
>>> -------------------------------------------------------------------------------
>>> 
>>> 2022-08-19 10:09:53.301888-0400 emacs[92880:17395371] fopen failed for data file: errno = 2 (No such file or directory) (hmnn?)
>>> 
>>> This time I had to use:
>>> 
>>> /Users/james/Code/emacs/src/emacs
>>> 
>>> instead of $ lldb ../nextstep/Emacs.app/Contents/MacOS/Emacs (which crashed on startup)
>>> 
>> 
>> I don't quite understand.  I've seen to open errors in your log.  Are
>> you saying that these happen because you started Emacs from src this
>> time?  FWIW, I don't see differences when starting one or the other.
>