Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDLView resetCursorRects crash with (FFmpeg 7) ffplay #9745

Open
kevleyski opened this issue May 10, 2024 · 8 comments
Open

SDLView resetCursorRects crash with (FFmpeg 7) ffplay #9745

kevleyski opened this issue May 10, 2024 · 8 comments
Milestone

Comments

@kevleyski
Copy link

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
Copy link
Author

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

./src/video/cocoa/SDL_cocoawindow

@kevleyski
Copy link
Author

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

@slouken slouken added this to the 3.2.0 milestone May 10, 2024
@slouken
Copy link
Collaborator

slouken commented May 10, 2024

What's your ffplay command line?

@kevleyski
Copy link
Author

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
Copy link

natbro commented May 10, 2024

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
Copy link
Contributor

mrpippy commented May 16, 2024

@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

👋 @natbro I filed FB13800881

@kevleyski
Copy link
Author

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
Copy link
Contributor

mrpippy commented May 18, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants