[SDL] odd crash with SDL2

Scott Percival moralrecordings at gmail.com
Tue Mar 19 14:55:21 PDT 2013

Actually that's not a bad idea. See if you can get the user to run the
game through apitrace - http://apitrace.github.com. All they'd have to
do is:
- Download the latest Windows build from
- Unpack it to somewhere that's easy to type (e.g. C:\apitrace)
- Open up a cmd.exe prompt, get them to cd to the game path
- Run "C:\apitrace\x86\bin\apitrace.exe trace gamename.exe"

This makes a portable dump of just the OpenGL-related calls, and
should stop logging at the one before the crash. Ask them to send the
.trace file that's just been made in the game directory and post it up

On 20 March 2013 00:34, Forest Hale <havoc at ghdigital.com> wrote:
> The NVS is a business/CAD GPU not a regular consumer GPU like the Geforce series is, its drivers are rather different for OpenGL to improve performance on CAD apps (I think the Direct3D ones are
> identical though).
> Regardless, mobile GPUs are often bound by support contracts where only the laptop vendor is allowed to release drivers for a given laptop, so when it gets end-of-life you have a problem, sometimes
> these drivers are modified to keep GPU clocks below certain levels for power saving or even engineering reasons (running the part full speed may be very ill-advised).
> On AMD GPUs there is a thing called Mobility Modder which modifies desktop drivers to accept laptop (Radeon Mobility) parts, but I do not know the equivalent for NVIDIA drivers.
> It is possible it is using the stock Windows driver also, which has often been buggy at launch (I remember severe graphics issues on some nvidia GPUs when using the stock Windows XP driver for
> instance), in which case the user needs to get the latest drivers from the laptop vendor website.
> In this particular case it may be best to investigate the underlying crash and work around the driver bug rather than asking users to modify driver installers to get newer desktop drivers onto their
> end-of-life laptop.
> It could be a call to an API in such a way that was never tested in the driver version in question - so checking which gl calls are made by SDL_CreateWindow is worthwhile.
> On 03/19/2013 01:58 AM, Scott Percival wrote:
>> It's pretty tricky, I think you might be right suspecting that OpenGL
>> is responsible.
>> The graphics chip you mentioned is a laptop variant (for some reason
>> NVIDIA refuse to support these properly in their Windows driver
>> updates), and pretty old (equivalent to the Geforce Go 7300, I have a
>> test machine with that one and it only works with the "legacy" driver
>> under Linux). Probably worth getting the full details from dxdiag just
>> for some more information (e.g. chip type, driver version, driver
>> date).
>> You could easily find out what bit of SDL is tripping up with a debug
>> build of the game/libSDL2 with just a backtrace from gdb, but
>> unfortunately this'd require convincing the user to get a portable
>> MinGW toolchain and have a go at building/debugging it. Or you could
>> try instrumenting with something like Breakpad which generates
>> portable stack dumps - http://code.google.com/p/google-breakpad , but
>> it looks like complete overkill for something like this.
>> (btw, worth mentioning that SDL_GL_SetAttribute only has an effect if
>> you call it before creating a window, you should move that block up
>> before SDL_CreateWindow)
>> On 19 March 2013 14:32, D B <buckyballreaction at gmail.com> wrote:
>>> Hi,
>>> I work on the game 'Bitfighter'.  We have support for both SDL 2 and
>>> SDL 1.2 in the game.  We recently moved our Mac and Windows ports to
>>> use SDL2 permanently because it provided much better window
>>> management.
>>> However, someone showed up in our IRC channel saying that it crashes
>>> for him.  I sent him a debug binary with loads of printf statements to
>>> find out where the crash was and the last statement printed directly
>>> before SDL_CreateWindow here:
>>> https://code.google.com/p/bitfighter/source/browse/zap/VideoSystem.cpp#117
>>> The game crashes right there and the SDL_GetError() call below it is
>>> never invoked.
>>> He is running Windows XP on a Dell D620 with graphics card NVIDIA
>>> Quadro NVS 110m.
>>> I had him install the nvidia drivers (thinking it may be an OpenGL
>>> issue) but it didn't work.  He can run an older version of our game
>>> that used SDL 1.2 just fine, but not the SDL2 port.
>>> Would anyone have an idea of might cause this?
>>> I know it's really hard to debug on a machine one doesn't have access
>>> to, but any help would be appreciated.
>>> Thanks!
>>> D
>>> _______________________________________________
>>> SDL mailing list
>>> SDL at lists.libsdl.org
>>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
> --
> LordHavoc
> Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
> Co-designer of Nexuiz - http://alientrap.org/nexuiz
> "War does not prove who is right, it proves who is left." - Unknown
> "Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
> "A game is a series of interesting choices." - Sid Meier
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

More information about the SDL mailing list