Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenGL initialization crash on XP, unable to fall back to software renderer #2835

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Closed

Comments

@SDLBugzilla
Copy link
Collaborator

SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.7
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2018-02-24 22:08:46 +0000, Brad Smith wrote:

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.

  1. 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.

  1. SDL_render_gl.c: GL_ActivateRenderer

On line 303, GL_UpdateViewport is called.

  1. 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?

On 2018-02-24 22:31:10 +0000, Brad Smith wrote:

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?

On 2018-02-24 22:55:30 +0000, Brad Smith wrote:

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

On 2018-02-25 08:08:30 +0000, Brad Smith wrote:

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.)

On 2019-06-16 21:28:00 +0000, Brad Smith wrote:

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.

On 2019-06-16 21:39:07 +0000, Ryan C. Gordon wrote:

We should fix this in any case, but shouldn’t this be using the Direct3D renderer before OpenGL...?

--ryan.

On 2019-06-18 23:03:39 +0000, Ryan C. Gordon wrote:

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.

On 2019-06-18 23:06:58 +0000, Ryan C. Gordon wrote:

(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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant