GNU bug report logs - #57267
28.1; crash when loading too many images on macOS

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: james <at> jojojames.com
Cc: 57267 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#57267: 28.1; emacs crashes when loading too many images
Date: Sat, 20 Aug 2022 08:34:12 +0200

james <at> jojojames.com writes:

>
> -------------------------------------------------------------------------------
> $ git log --oneline -1
> 8f1d0295bc (HEAD -> master, origin/master, origin/HEAD) Speed up image-dired-display-image
> (END)
> -------------------------------------------------------------------------------

Thanks.

> Process 92880 stopped
> * thread #17, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
>     frame #0: 0x0000000000000000
> error: memory read failed for 0x0
> Target 0: (emacs) stopped.

Too bad, that means ASAN didn't find a problem before the bad access happens.

> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread'
...
>     frame #42: 0x0000000100a1a9ce emacs`ns_dumpglyphs_image(s=0x00007ffeefbf5a60, r=(origin = (x = 10, y = 566), size = (width = 700, h>     frame #50: 0x0000000100012156 emacs`update_frame(f=0x0000621002046130, force_p=true, inhibit_hairy_id_p=false) at dispnew.c:3279:18
>     frame #51: 0x0000000100122312 emacs`redisplay_internal at xdisp.c:17096:14
>     frame #52: 0x0000000100135fd9 emacs`redisplay at xdisp.c:16103:3

Emacs' thread (#1) is displaying an image when thread #17 crashes.

> (lldb) bt all
>   thread #4, name = 'gmain'
>     frame #0: 0x00007fff20477646 libsystem_kernel.dylib`__select + 10
>     frame #1: 0x00000001029f056b libglib-2.0.0.dylib`g_poll + 505

That's a select for some reason, doing nothing.

>   thread #5
>     frame #0: 0x00007fff20473d52 libsystem_kernel.dylib`__pselect + 10
>     frame #1: 0x00007fff20473c6f libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 42
>     frame #2: 0x00000001009b2be5 emacs`-[EmacsApp
>     fd_handler:](self=0x0000612000024640, _cmd="fd_handler:",
>     unused=0x0000000000000000) > (lldb)

Also doing nothing.

>  thread #17
>    frame #0: 0x0000000000000000
>    frame #1: 0x00007fff31a448da AppleVPA`___lldb_unnamed_symbol479$$AppleVPA + 336
>    frame #2: 0x00007fff31a427ec AppleVPA`___lldb_unnamed_symbol455$$AppleVPA + 254
>    frame #3: 0x00007fff204a48fc libsystem_pthread.dylib`_pthread_start + 224
>    frame #4: 0x00007fff204a0443 libsystem_pthread.dylib`thread_start +
>    15

That's the culprit, but I have no real idea what this thread is for.
One of the few things I could find on the web is
https://www.zerodayinitiative.com/advisories/ZDI-20-1182/ (a zero-day
vulnerability) which indicates that AppleVPA has something to do with
JPEG parsing.

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.