Hi, folks!
I’ve recently upgraded my game’s SDL2 build from version 2.0.12 to 2.0.22 (I was certain I had upgraded to 2.0.18 months ago, but apparently not?). Since this update, I have begun getting some SDL2 crash reports from Windows users, where it previously had been rock solid.
We don’t have a 100% set of crash repro steps yet, but the crash happens in the middle of gameplay at seemingly random times, often after minutes or hours of play. Some players see these crashes frequently, some rarely, and others (I suspect the large majority) don’t ever get it at all. I’ve never seen it happen myself, even after quite a lot of testing.
I don’t have any real clues in trying to track it down, and since it doesn’t seem to ever occur for me, it’s hard for me to debug apart from what I can get in our crash logs.
The crash seems to only happen when we call SDL_SetRelativeMouseMode(SDL_TRUE) (weirdly, I’ve never seen a crash report happen when we call it with SDL_FALSE). Our crash dumps give us this callstack for the crash:
MT2.exe caused an Access Violation at location 00007FFEC10D5826 in module SDL2.dll Writing to location 0000000000000040.
AddrPC Params
00007FFEC10D5826 00000001118B1180 0000000000000017 0000000000000017 SDL2.dll!SDL_DYNAPI_entry
00007FFEC10D5E67 000000002935AA50 0000000007441A01 0000000001ABFDB0 SDL2.dll!SDL_DYNAPI_entry
000000000098338D 0000000000000000 000000003F800000 0000000000000000 MT2.exe!vsInput::CaptureMouse
<... other stuff inside the game itself ...>
(I’m assuming that we’re missing debug symbols for SDL2.dll, and SDL_DYNAPI_entry is actually just the only symbol the crash handler was able to find, rather than actually being where the crash occurred)
This is using the SDL2 libraries from the official release, from this package on the libsdl.org site: SDL2-devel-2.0.22-mingw.tar.gz (all our Windows builds are compiled using mingw)
This happens for me both with and without setting SDL_HINT_MOUSE_AUTO_CAPTURE to false. (I figured that changes made to mouse capturing in 2.0.22 might have been part of the problem, but I’m still getting occasional crash reports after having set the hint to false to try to revert to older behaviour, so it might be entirely unrelated)
I’ve verified that when the crash happens, we’re dynamically linking against a real SDL 2.0.22 DLL; it doesn’t appear to be a case of an end-user providing a different DLL that’s getting used instead of the one we intended.
Does anybody have suggestions about what I should be doing next to try to track this down? I’m tempted to try backing us off to 2.0.20, but obviously that’s not a real solve for the problem, whatever the problem turns out to be.
Definitely would appreciate any input on stuff I should be trying/checking!
