We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4093

Summary: OpenGL initialization crash on XP, unable to fall back to software renderer
Product: SDL Reporter: Brad Smith <rainwarrior+libsdl>
Component: renderAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: icculus
Version: 2.0.7Keywords: target-2.0.10
Hardware: x86   
OS: Windows (XP)   
See Also: https://bugzilla.libsdl.org/show_bug.cgi?id=4675

Description Brad Smith 2018-02-24 22:08:46 UTC 
When trying to create a renderer on older XP systems, the attempt to create an OpenGL renderer appears to crash with an access violation, preventing itself from returning with an error and falling back to the software renderer. My current theory is that this happens with XP installations that have no graphics driver to elevate its OpenGL verison above 1.1 but I'm not certain.

This is the sequence of events leading to the crash:


1. SDL_render_gl.c: GL_CreateRenderer

On line 468, GL_LoadFunctions returns with a failure. GL_DestroyRenderer is called, presumably to clean up the partial initialization before returning an error.

2. SDL_render_gl.c: GL_DestroyRenderer

On line 1589, GL_ActivateRenderer is called. I'm not sure if this is already a mistake. The data->context is not NULL here, but the OpenGL function pointers contained by data are mostly invalid, since GL_LoadFunctions failed.

3. SDL_render_gl.c: GL_ActivateRenderer

On line 303, GL_UpdateViewport is called.

4. SDL_render_gl.c: GL_UpdateViewport

On line 1095 we have an access violation while calling glMatrixMode, which appears to be NULL because GL_LoadFunctions had failed before retrieving it. (Apparently glViewport called a little bit above was fine.)


This did not happen with SDL 2.0.0 but I'm not sure what has changed between this and 2.0.7. Maybe a requirement for a later version of OpenGL is newly being demanded via functions from GL_LoadFunctions that is exposing this problem?
Comment 1 Brad Smith 2018-02-24 22:31:10 UTC 
Turning on verbose logs before SDL_CreateRenderer, I get:

DEBUG: CreateDevice(): INVALIDCALL 
DEBUG: Couldn't load GL function glBlendEquation: CreateDevice(): INVALIDCALL 

I assume the first CreateDevice is failing to create a direct3D renderer? (By the way, intalling the DX9c runtime does not seem to help with this, still gets to the OpenGL attempt.)

glBlendEquation is not in OpenGL 1.1, which would explain the failure, but maybe just moving >1.1 functions to the bottom of the procedure list would be enough to get it to finish failing the initialization instead of crashing so it can fall back.

It would still be a problem if it got this far and failed to get the functions that /are/ being used here. Unsure if it's possible to get a context but fail the function load on 1.1 functions only, but the UpdateViewport already looks like a problem just by itself?
Comment 2 Brad Smith 2018-02-24 22:55:30 UTC 
So, trying that as an experiment, moving the two offending functions to the bottom of the list (glBlendEquation, glBlendFuncSeparate), it does get through the initialization attempt with an error, at least.

However, it never falls back to software rendering, which I thought was supposed to be an option? The application will run if I set SDL_VIDEO_DRIVER=software, but otherwise it has a "Couldn't find matching render driver" error.

Log of this, if it's useful:

DEBUG: CreateDevice(): INVALIDCALL 
DEBUG: Couldn't load GL function glBlendEquation: CreateDevice(): INVALIDCALL 
DEBUG: Failed loading d3dcompiler_43.dll: The specified module could not be found. 
DEBUG: Failed loading libGLESv2.dll: The specified module could not be found. 
DEBUG: Could not initialize OpenGL / GLES library 
DEBUG: Couldn't find matching render driver
Comment 3 Brad Smith 2018-02-25 08:08:30 UTC 
> However, it never falls back to software rendering, which I thought was
> supposed to be an option? The application will run if I set
> SDL_VIDEO_DRIVER=software, but otherwise it has a "Couldn't find matching
> render driver" error.

Not falling back to the software renderer was apparently due to using SDL_RENDERER_PRESENTVSYNC in the application I was testing, so that part I understand now, though it's interesting that SDL_VIDEO_DRIVER is apparently allowed to bypass that request?

(The primary problem of the OpenGL attempt access violation remains, though.)
Comment 4 Brad Smith 2019-06-16 21:28:00 UTC 
Sorry if my previous comments were a bit rambly, but this is the solution I have been using for the past year or so:

src/render/opengl/SDL_glfuncs.h

Move these two entries to the bottom of the list:

SDL_PROC(void, glBlendEquation, (GLenum))
SDL_PROC(void, glBlendFuncSeparate, (GLenum, GLenum, GLenum, GLenum))

That by itself appeared to be enough for systems that don't have OpenGL 1.1 to avoid crashing and fall back to software rendering.
Comment 5 Ryan C. Gordon 2019-06-16 21:39:07 UTC 
We should fix this in any case, but shouldn’t this be using the Direct3D renderer before OpenGL...?

--ryan.
Comment 6 Ryan C. Gordon 2019-06-18 23:03:39 UTC 
I made the failing case you describe more robust here:

https://hg.libsdl.org/SDL/rev/b8d437d42151

GL_ActivateRenderer() is also safe to call now, since it only makes the GL context current, since the renderer code was redesigned for 2.0.9.

I believe between those redesigns and this patch, we can confidently close this bug. However, I'll open another about why D3D9 doesn't work on Windows XP, so we remember to investigate that.

--ryan.
Comment 7 Ryan C. Gordon 2019-06-18 23:06:58 UTC 
(In reply to Ryan C. Gordon from comment #6)
> However, I'll open another about why D3D9 doesn't work on Windows
> XP, so we remember to investigate that.

That bug is now https://bugzilla.libsdl.org/show_bug.cgi?id=4675

--ryan.