SDL2 program linked against FB's folly library crashes

SDL Development
1

I posted a lengthy-ish reply on the Stack Overflow forum, asking for more info. (TL;DR - I wasn’t able to repro this, but I think my dev environment might have significant-enough differences to alter the end-state).

I’m happy to try further debugging, either on Stack Overflow, here (in the SDL forums), or elsewhere, depending on what would help other(s).

Most of my familiarity with SDL’s internals lies in the UWP backend, but I’ve done some amount of work on Apple platforms, mostly outside of SDL (and mostly with iOS, but some OSX, too).

Cheers!
– David L.

2

ross.vander wrote:

After changing the way I link against SDL2, I still see the same crash.

Weird. I’m still stumped about what’s causing the problem.

Here’s what I get when I run g++ --version, as well as otool -L prog:

Code:

davidl at Wart ~/Documents/Code/SDL/bugs/folly_crash $ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.3.0 (clang-703.0.31)
Target: x86_64-apple-darwin15.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
davidl at Wart ~/Documents/Code/SDL/bugs/folly_crash $ otool -L prog
prog:
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/sdl2/lib/libSDL2-2.0.0.dylib (compatibility version 5.0.0, current version 5.0.0)
/usr/local/opt/folly/lib/libfolly.57.dylib (compatibility version 58.0.0, current version 58.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
davidl at Wart ~/Documents/Code/SDL/bugs/folly_crash $

A copy of the files I used to make my build, along with an actual build, is up at https://www.dropbox.com/s/74nt44cyttjcx2n/folly_crash-DavidL.zip?dl=0 , if it helps.

I get no crash, when running ‘./prog’.

Maybe my copies of SDL2 and/or Folly are out of date? I installed them via brew, earlier this afternoon (I had only used locally-built copies of SDL, before that). Might there be a brew package-list-updating command, that I’d need to run?

Other thoughts welcomed, at this point.

– David L.

3

The crash info posted to Stack Overflow only lists one frame’s worth of info. Does lldb report a deeper callstack than that? If so, what’s in it?

4

Here are some other thought(s) for things to try, in no particular order:

  1. link against SDL and Folly, statically, then see if that crashes

  2. try reducing your program down to the bare minimum. Something like:

Code:

int main(int, char **) {
SDL_Event event;
SDL_CreateWindow(“SDL app”, SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 640, 640, 0);
while (1) {
SDL_PollEvent(&event);
}
return 0;
}

  1. try running a program with just Folly, removing or replacing all SDL calls, and see if it crashes
5

More thoughts on things to try:

  1. try linking against an SDL-official copy of SDL, as downloaded from https://libsdl.org/download-2.0.php

  2. try compiling your own version(s) of SDL and/or Folly, and linking against those. If you have a copy of Xcode ready, compiling SDL is usually pretty straight-forward: open SDL/Xcode/SDL/SDL.xcodeproj, choose one of the build targets in the drop-down near the top-left of the Xcode window (includes: “Framework”, “Static Library”, and “Shared Library”, among others). I’m not sure about Folly.

6

Odd. The crash is occurring in a dying thread. I wonder what the thread is, who spawned it, and what the history of the app’s memory was.

Here’s something to try, that might provide info: try building and running the program using Clang’s ‘Address Sanitizer’. It’s usually pretty good at giving a lot more info on why bad memory accesses occur. To set it up, it’s a matter of passing in a few extra flags to the compiler. Details at http://clang.llvm.org/docs/AddressSanitizer.html

7

ross.vander wrote:

I don’t have an explanation for why -fsanitize=address seems to have stopped the crashing…

This is getting odder by the minute…

You mentioned that narrowing down the code (suggestion #2) to a bare-minimum removed the crash. Maybe try starting with your original, crashing program, then start removing/commenting-out calls, until you hit a point where the crash doesn’t occur. I.e. see if there is one call that, ultimately, leads to a crash.

8

Another thought: The following compiler bug, or one like it, generated faulty code, perhaps in a pre-built copy of SDL2 and/or Folly, as provided by brew

http://www.openradar.me/25704040

– David L.