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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 19 Aug 2022 08:55:16 +0300

> From: [email-masked]
> Date: Thu, 18 Aug 2022 16:14:26 -0400
> Cc: [email-masked]
> 
> Process 35748 stopped
> * thread #44, stop reason = EXC_BAD_ACCESS (code=2, address=0x718b828a0)
>     frame #0: 0x0000000718b828a0
> ->  0x718b828a0: addb   %al, (%rax)
>     0x718b828a2: addb   %al, (%rax)
>     0x718b828a4: addb   %al, (%rax)
>     0x718b828a6: addb   %al, (%rax)
> Target 0: (Emacs) stopped.
> (lldb)

Thread 44 doesn't look like our thread.  If it stopped due to
EXC_BAD_ACCESS, then I don't know what to say about this.

Thread 1, which is the main Lisp thread, seems to be inside the Apple
library that handles JPEG images:

> (lldb) thread select 1
> * thread #1, queue = 'com.apple.main-thread'
>     frame #0: 0x00007fff204709de libsystem_kernel.dylib`__ulock_wait + 10
> libsystem_kernel.dylib`__ulock_wait:
> ->  0x7fff204709de <+10>: jae    0x7fff204709e8            ; <+20>
>     0x7fff204709e0 <+12>: movq   %rax, %rdi
>     0x7fff204709e3 <+15>: jmp    0x7fff2046fac9            ; cerror_nocancel
>     0x7fff204709e8 <+20>: retq
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread'
>   * frame #0: 0x00007fff204709de libsystem_kernel.dylib`__ulock_wait + 10
>     frame #1: 0x00007fff204a5f60 libsystem_pthread.dylib`_pthread_join + 362
>     frame #2: 0x00007fff31a4287c AppleVPA`___lldb_unnamed_symbol456$$AppleVPA + 132
>     frame #3: 0x00007fff31a3abde AppleVPA`___lldb_unnamed_symbol279$$AppleVPA + 72
>     frame #4: 0x00007fff2066775a CoreFoundation`_CFRelease + 244
>     frame #5: 0x00007fff2053e583 CoreFoundation`__RELEASE_OBJECTS_IN_THE_ARRAY__ + 118
>     frame #6: 0x00007fff2053e4c6 CoreFoundation`-[__NSArrayM dealloc] + 279
>     frame #7: 0x00007fff2c082f12 MediaToolbox`___lldb_unnamed_symbol186$$MediaToolbox + 270
>     frame #8: 0x00007fff2066775a CoreFoundation`_CFRelease + 244
>     frame #9: 0x00007fff28b7ce57 ImageIO`AppleJPEGReadPlugin::copyIOSurfaceCallback(InfoRec*, CGImageProvider*, __CFDictionary const*) + 1229
>     frame #10: 0x00007fff28b7d570 ImageIO`AppleJPEGReadPlugin::createImageBlockSetWithHardwareDecode(InfoRec*, CGImageProvider*, CGSize, __CFDictionary const*) + 154
>     frame #11: 0x00007fff28b0f679 ImageIO`AppleJPEGReadPlugin::copyImageBlockSet(InfoRec*, CGImageProvider*, CGRect, CGSize, __CFDictionary const*) + 1955
>     frame #12: 0x00007fff28b0e998 ImageIO`IIO_Reader::CopyImageBlockSetProc(void*, CGImageProvider*, CGRect, CGSize, __CFDictionary const*) + 100
>     frame #13: 0x00007fff28b2c527 ImageIO`IIOImageProviderInfo::copyImageBlockSetWithOptions(CGImageProvider*, CGRect, CGSize, __CFDictionary const*) + 663
>     frame #14: 0x00007fff28b0e8d0 ImageIO`IIOImageProviderInfo::CopyImageBlockSetWithOptions(void*, CGImageProvider*, CGRect, CGSize, __CFDictionary const*) + 680
>     frame #15: 0x00007fff250e82d0 CoreGraphics`imageProvider_retain_data + 77
>     frame #16: 0x00007fff250e8246 CoreGraphics`CGDataProviderRetainData + 75
>     frame #17: 0x00007fff250e826b CoreGraphics`provider_for_destination_retain_data + 17
>     frame #18: 0x00007fff250e8246 CoreGraphics`CGDataProviderRetainData + 75
>     frame #19: 0x00007fff250e80f6 CoreGraphics`CGAccessSessionCreate + 98
>     frame #20: 0x00007fff250e9e57 CoreGraphics`get_access_session + 44
>     frame #21: 0x00007fff250e954c CoreGraphics`img_raw_read + 1302
>     frame #22: 0x00007fff251440f9 CoreGraphics`img_interpolate_read + 753
>     frame #23: 0x00007fff250e75bc CoreGraphics`img_data_lock + 6164
>     frame #24: 0x00007fff250e22f0 CoreGraphics`CGSImageDataLock + 1230
>     frame #25: 0x00007fff250e1de9 CoreGraphics`RIPImageDataInitializeShared + 164
>     frame #26: 0x00007fff250e1aaa CoreGraphics`RIPImageCacheGetRetained + 750
>     frame #27: 0x00007fff250e1574 CoreGraphics`ripc_AcquireRIPImageData + 384
>     frame #28: 0x00007fff250e02a1 CoreGraphics`ripc_DrawImage + 1180
>     frame #29: 0x00007fff250df4f7 CoreGraphics`CGContextDrawImageWithOptions + 454
>     frame #30: 0x00007fff22f119c5 AppKit`__74-[NSImageRep drawInRect:fromRect:operation:fraction:respectFlipped:hints:]_block_invoke + 902
>     frame #31: 0x00007fff22f114fa AppKit`-[NSImageRep drawInRect:fromRect:operation:fraction:respectFlipped:hints:] + 936
>     frame #32: 0x00007fff233b1dbc AppKit`__71-[NSImage drawInRect:fromRect:operation:fraction:respectFlipped:hints:]_block_invoke.1340 + 967
>     frame #33: 0x00007fff22eea8b9 AppKit`-[NSImage _usingBestRepresentationForRect:context:hints:body:] + 129
>     frame #34: 0x00007fff22f10ec1 AppKit`-[NSImage drawInRect:fromRect:operation:fraction:respectFlipped:hints:] + 1359
>     frame #35: 0x000000010049358c Emacs`ns_dumpglyphs_image(s=0x00007ffeefbfa220, r=(origin = (x = 10, y = 222), size = (width = 700, height = 507))) at nsterm.m:3952:7
>     frame #36: 0x000000010048f75e Emacs`ns_draw_glyph_string(s=0x00007ffeefbfa220) at nsterm.m:4349:7
>     frame #37: 0x0000000100092b81 Emacs`draw_glyphs(w=0x0000000106152630, x=672, row=0x000000010424f700, area=TEXT_AREA, start=0, end=20, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:30449:5

So again, I don't see what that has to do with Emacs.

OTOH, redisplay works on macOS very differently from other platforms,
so maybe we are somehow causing this?