search

libsdl-org / SDL

Simple Directmedia Layer
https://libsdl.org
zlib License
10.18k stars 1.86k forks source link

SDLView resetCursorRects crash with (FFmpeg 7) ffplay #9745

Open kevleyski opened 6 months ago

kevleyski commented 6 months ago

Hi this looks to be a recent issue I have latest greatest macOS Sonoma, brew install ffmpeg, I'm consistency hitting this (I'll double check with latest SDL lib, but putting it here sos others find it)

0 ??? 0xbad4007 ??? 1 ImageIO 0x7ff825e66a5a 0x7ff825d3c000 + 1223258 2 ImageIO 0x7ff825d49a71 0x7ff825d3c000 + 55921 3 ImageIO 0x7ff825d52bd2 0x7ff825d3c000 + 93138 4 AppKit 0x7ff81e7ed28b 0x7ff81e696000 + 1405579 5 AppKit 0x7ff81e931f7e 0x7ff81e696000 + 2735998 6 AppKit 0x7ff81e93177b 0x7ff81e696000 + 2733947 7 libSDL2-2.0.0.dylib 0x10b4d66a4 +[NSCursor(InvisibleCursor) invisibleCursor] + 104 8 libSDL2-2.0.0.dylib 0x10b4dde1b Cocoa_GetDesiredCursor + 59 9 libSDL2-2.0.0.dylib 0x10b4dea2e -[SDLView resetCursorRects] + 73

zsh: segmentation fault

kevleyski commented 6 months ago

If I comment out the call to resetCursorRects ffplay is good (SDL2 branch)

./src/video/cocoa/SDL_cocoawindow

kevleyski commented 6 months ago

Could be Apple's bug Sonoma 14.4.1 (23E224)

slouken commented 6 months ago

What's your ffplay command line?

kevleyski commented 6 months ago

What's your ffplay command line?

I found it didn't matter so I didn't provide an example

Anything that would cause a window to show, which is pretty much anything, image, video, lavfi test source it doesn't matter

natbro commented 6 months ago

Heya @kevleyski - could you capture a sysdiagnose soon after this happens and post here or send to natbro@apple.com, or file a feedback (https://feedbackassistant.apple.com) soon after (this will automagically grab system traces). Neither Sam nor I are able to reproduce this from just the direct API calls, so there may be something more to the window and circumstance which a full trace would help us uncover.

mrpippy commented 6 months ago

@kevleyski Do you have DYLD_LIBRARY_PATH set? If DYLD_LIBRARY_PATH is set to a directory that contains a libpng.dylib (or likely libjpeg.dylib, libgif.dylib, libtiff.dylib, libjp2.dylib), ImageIO will load that libpng instead of its own, and then crash since it's the wrong library. DYLD_FALLBACK_LIBRARY_PATH is safer, and doesn't have this issue.

Here's a test app to show the crash: test.c.txt

:wave: @natbro I filed FB13800881

kevleyski commented 6 months ago

I'm my case I'm running vanilla Homebrew install of FFmpeg (on an Intel MacBook running latest patches of Sonoma, for me it's a recent issue)

I tried a few versions of FFmpeg including latest greatest from their git, it's not FFmpeg as far as I can tell causing this but I can try setting the dynamic library path for the other libs

The call stack doesn't seem to show problems from PNG etc but agree it's good to eliminate any cause/effect

mrpippy commented 6 months ago

I'm my case I'm running vanilla Homebrew install of FFmpeg (on an Intel MacBook running latest patches of Sonoma, for me it's a recent issue)

I tried a few versions of FFmpeg including latest greatest from their git, it's not FFmpeg as far as I can tell causing this but I can try setting the dynamic library path for the other libs

The call stack doesn't seem to show problems from PNG etc but agree it's good to eliminate any cause/effect

Yeah libpng won't show up in the call stack, ImageIO crashes trying to call a function from its own libpng which doesn't exist in a Homebrew libpng (or could be a libtiff, libgif, libjpeg, etc.):

  * frame #0: 0x000000000bad4007
    frame #1: 0x00007ff814c9c793 ImageIO`PNGReadPlugin::InitializePluginData(IIOImageReadSession*, IIODictionary*, IIODictionary*, CGImageMetadata*, CGColorSpace**, ReadPluginData&, PNGPluginData&, __CFDictionary*) + 881
    frame #2: 0x00007ff814c9c41a ImageIO`PNGReadPlugin::initialize(IIODictionary*) + 62
    frame #3: 0x00007ff814c9459d ImageIO`IIOReadPlugin::callInitialize() + 403
    frame #4: 0x00007ff814c94364 ImageIO`IIO_Reader::initImageAtOffset(CGImagePlugin*, unsigned long, unsigned long, unsigned long) + 84
    frame #5: 0x00007ff814c91cdd ImageIO`IIOImageSource::makeImagePlus(unsigned long, IIODictionary*) + 707
    frame #6: 0x00007ff814cfe268 ImageIO`IIOImageSource::createImageAtIndex(unsigned long, IIODictionary*, int*) + 106
    frame #7: 0x00007ff814c9e9fb ImageIO`CGImageSourceCreateImageAtIndex + 323
    frame #8: 0x00007ff80f5091d8 CoreGraphics`CGImageCreateWithPNGDataProvider + 151
    frame #9: 0x00000001001afef6 test`main + 70

If you run echo $DYLD_LIBRARY_PATH at a terminal, does it print anything? Can you try compiling/running the test code I attached?

slouken commented 1 month ago

We are scoping work for the SDL 3.2.0 release, so please let us know if this is a showstopper for you.

kevleyski commented 12 hours ago

I still see this with latest everything ffplay 7.1.3 on Sequioa 15.1.1 (24B91)) Intel CPU w/ AMD Radeon

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 0xbad4007 ??? 1 ImageIO 0x7ff81b60f805 IIO_Reader_GIF::parse(IIOImageReadSession, IIODictionary, CGImageSourceStatus, unsigned int, IIODictionary) + 127 2 ImageIO 0x7ff81b68ffae IIO_Reader::callGetImageCount(CGImageReadSession, IIODictionary, CGImageSourceStatus, int*) + 582 3 ImageIO 0x7ff81b545577 IIOImageSource::updatedCount() + 305 4 ImageIO 0x7ff81b54ec47 CGImageSourceGetCount + 214 5 AppKit 0x7ff81360e2cb +[NSBitmapImageRep _imagesWithData:hfsFileType:extension:zone:expandImageContentNow:includeAllReps:] + 353 6 AppKit 0x7ff813751a36 +[NSBitmapImageRep imageRepsWithData:] + 69 7 AppKit 0x7ff813751224 -[NSImage initWithData:] + 93 8 libSDL2-2.0.0.dylib 0x1033c0390 +[NSCursor(InvisibleCursor) invisibleCursor] + 104 9 libSDL2-2.0.0.dylib 0x1033c7bfd Cocoa_GetDesiredCursor + 59 10 libSDL2-2.0.0.dylib 0x1033c8810 -[SDLView resetCursorRects] + 73

If others areseeing this too I've a quick hack workaround here which I use for ffplay to work https://github.com/kevleyski/SDL/commit/8c605478363f2106df008228baa2a4a30bf55c4c