From: Eli Zaretskii <eliz@gnu.org>
To: james@jojojames.com
Cc: 57267@debbugs.gnu.org
Subject: bug#57267: 28.1; emacs crashes when loading too many images
Date: Fri, 19 Aug 2022 08:55:16 +0300 [thread overview]
Message-ID: <837d34g4l7.fsf@gnu.org> (raw)
In-Reply-To: <E6EC8DC3-9CE0-4648-9B34-26820059115B@jojojames.com>
> From: james@jojojames.com
> Date: Thu, 18 Aug 2022 16:14:26 -0400
> Cc: 57267@debbugs.gnu.org
>
> 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?
next prev parent reply other threads:[~2022-08-19 5:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-18 0:38 bug#57267: 28.1; emacs crashes when loading too many images james
2022-08-18 6:30 ` Eli Zaretskii
2022-08-18 18:49 ` james
2022-08-18 19:03 ` Eli Zaretskii
2022-08-18 20:14 ` james
2022-08-19 5:55 ` Eli Zaretskii [this message]
2022-08-19 6:01 ` james
2022-08-19 7:18 ` Gerd Möllmann
2022-08-19 7:22 ` Gerd Möllmann
2022-08-19 14:18 ` james
2022-08-20 6:34 ` Gerd Möllmann
2022-08-20 16:23 ` james
2022-08-20 16:29 ` james
2022-08-21 5:42 ` Gerd Möllmann
2022-08-21 5:30 ` Gerd Möllmann
2022-08-21 21:21 ` james
2022-08-23 5:09 ` Gerd Möllmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=837d34g4l7.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=57267@debbugs.gnu.org \
--cc=james@jojojames.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).