Occasional failures of wglCreateContextAttribsARB() inside WglContext::createCon

[GatoRat]

I'm getting occasional failures of wglCreateContextAttribsARB() inside WglContext::createContext which is, in turn, being called by sf:RenderTexture::create. When this happens, the fallback call to wglCreateContext also fails. Once this happens, the failures continue.

The program will successfully run for hours or even days before the error happens. and, though it may not be relevant, all Sprites/Textures not created using RenderTexture continue to work.

This is with Visual Studio 2015 64-bit, SFML 2.4.2 (and 2.3.2). The system which breaks the most often (relatively speaking) is Windows 7 64 with Intel HD 2500 graphics. I've had it fail once on my dev system; Windows 10 64 with Intel HD Graphics 530.

I'm writing small programs in an attempt to have the failure happen more predictably, but in the meantime, does anyone have any ideas?

[eXpl0it3r]

After hours and days of running, the Intel driver probably does something weird and woosh error.
What kind of application are you developing that runs for days?
Is the rest of the system idle?

[GatoRat]

The app is a promotional product which runs on both a tablet and wall display. The display shows what's happening on the tablet if the tablet is being used, or what happened on the tablet otherwise. The non-promo load on the display system is rather small. (I did run one test on my dev machine where I blasted the GPU with textures from a second program and the promo program didn't "blink.")

I'm highly suspicious of the Intel driver, but don't want to fall into the trap of just blaming it.

[eXpl0it3r]

Btw. can you post the complete errors you get?

[GatoRat]

With 2.3.2 (which we've been using because it's more stable) and 2.4.2 we tend to get:

Failed to create an OpenGL context for this window:  (Followed by gibberish since getErrorString has a bad implementation)

With just 2.4.2, we received the additional following error:

An internal OpenGL call failed in RenderTextureImplFBO.cpp(92).
Expression:
   GLEXT_glGenFramebuffers(1, &frameBuffer)
Error description:
   GL_INVALID_OPERATION
   The specified operation is not allowed in the current state.

Impossible to create render texture (failed to create the frame buffer object)

* * *

What I then did was build the app with the debug version of 2.4.2 (since I was unable to build 2.3.2 without jumping through hoops) and put breakpoints in the methods producing the above. When they broke, I then backtracked and stepped through WglContext::createContext several times.

As a side note, I was running a very long test with 2.3.2 on my dev machine. I'd modified the code to run only the constructors of a select set of playback modes in a very methodical way. After running for almost 48 hours, I had six "Failed to create an OpenGL context for this window: NULNULÞ errors. The next iteration the program exited with no other warning.

UPDATE: I built a 2.3.2 release with debug version in VS 2015 by eliminating the FLAC and OGG support and rebuilding Freetype and libjpeg.

[eXpl0it3r]

So here's the thing, when you run intoan issue, you should solve the issue or at least try to understand it or the cause of it. Because as soon as you accept that things make act weird and break sometimes, you set yourself up for bigger "surprises" in the future.

getErrorString certainly works and when it doesn't for, then that's already the first sign of some problem.

Because strings implementation are rather complex and lots of optimizations are to be developed and thus they seem to be one of things that get changed for pretty much any new runtime version. For that reason, they are "good" indicator of wrong runtime usage.

Don't use release libraries in debug mode. Don't use debug libraries in release mode. Use the sane runtime library that yozr compiler uses. Use the correct redist.

Next make sure your Intel GPU driver is updated. Intel has a pretty bad record when it comes to GPU drivers, but they have gotten better, so if you're still using some old or default Windows driver, you shouldn't be surprised to run into issues.

Make sure you give SFML 2.4.2 a run. No modifications needed. If you do run into issues, write down when, how and what happened. SFML 2.4.2 comes with fixes to context handling that was broken in SFML 2.4.1. Since the release we haven't heard of any issues, so I'd be surprised if there still were some.

Do you use any multi-threading?

I do also recommend to create some minimal test case, e.g. just creating a render texture and nothing more. That way you can a) make sure it's not related to your more complex code and b) narrow down the issue to one specific area.

If you really want to build SFML 2.3.2, get the commit right after the release, it adds support for VS 2015, so no morr hoops to jump through, this one: https://github.com/SFML/SFML/commit/6b9781475d70272538a5ce48ad96f583f3a373c3

[GatoRat]

1) getErrorString has flaws:

- The length passed for FormatMessage is incorrect if TCHAR is longer than a byte
- System Messages returned in FormatMessage may have format markers; since you don't what they are beforehand, the FORMAT_MESSAGE_IGNORE_INSERTS should always be used.
- If a message cannot be found, the return buffer is not set to an empty string, so the return value of FormatMessage should be checked. If zero, the first character of the buffer should be set to zero.

2) Debug

I was not talking about mixing debug and release builds, but doing a release build WITH debug information on. Yes, many things get optimized away, but you can usually set breakpoints and get stack traces.

3) I've run into the same problem on both 2.3.2 and 2.4.2. In testing the error happened in 2.4.2 much more frequently with the actual release (versus the modified stress test code), hence the requirement given to me that 2.3.2 was to be used.

4) All calls to SFML occur on a single thread.

5) I've created stand alone tests, but so far all pass.

6) The 2.3.2 Release with Debug Info build I did this morning resulted in a failure extremely slightly different than with 2.4.2 in that when I allowed the program to switch to different playback "modules", they hadn't yet failed. Close examination of the failing "module" shows that it uses RenderTexture far more than any other module. I believe this can be refactored to reuse far fewer RenderTextures.

7) More research on my part found that Intel's OpenGL support has been less than optimal in the past, if not downright broken.