Search code examples
c++sdl-2hardware-acceleration

SDL_RenderPresent Hangs Forever


I've come across an inexplicable error in SDL 2.0.3 when using hardware rendered graphics. For some reason, around 5 minutes after the program starts my graphical window closes but my console window stays open. There is no error thrown or anything to signify a problem.

When I pause the debugger, the program puts the breakpoint inside of SDL_RenderPresent(). I followed the call stack to a function inside of ntdll.dll called WaitForSingleObject() but I'm not sure what's causing it to hang forever.

Also, this does not happen when I use software rendered graphics. I am running it on an AMD FirePro M5100 FireGL V with the latest drivers installed.

My question is, does anyone know what might cause SDL_RenderPresent() to never return?


Solution

  • From the description seems that there are locks not released by the lower levels of the graphics pipeline.

    From the fact that it happens after 5 minutes seems that there is a resource leak somewhere.

    All of this is just a wild guess of course, but I'd say that either the application code or the SDL code is leaking resources (handles to textures, vertex buffers and the like) and that part of the code (either at the lower levels of SDL or in the driver) when running out is not behaving nicely (this happens often... in many cases low-resource conditions are not very well tested and handled).

    This doesn't happen in software rendering because there resources are basically unlimited. A confirm of this kind of problem would be that when running in software rendering the program works but process memory use keeps growing and growing.

    Pay attention also to any code that "catches" any exception/failure and keeps running after that. Writing complex software that works correctly after an abnormal state is extremely difficult (basically impossible beyond trivial cases because exception safety doesn't scale by composition: the only way that doesn't make the complexity explode is to have logical partitioning "walls" and re-initialize whole subsystems).