Email from NVidia about BlitzMax graphics

Hey Josh,

I figured out what was going on our end. During your sample app's termination, you invoke exit(). You seem to have an atexit callback that cleans up your resources, and after that, exit calls ExitProcess. ExitProcess uses a big hammer to smash stuff, and that's where the problem pops up.

The app creates two contexts, but then only uses the second one created, such as FBO management. Then you delete that second context during application exit. However, that first context is never deleted. It only really matters because the app also calls wglShareLists between the two contexts, which unifies not only their display list namespace, but their FBO namespace too. That really isn't well documented anywhere, but at this point, it's expected behavior. It is kinda ridiculous (imo), but it is mentioned in issue 76 of the FBO EXT spec: http://opengl.org/registry/specs/EXT/framebuffer_object.txt

So when you call wglDeleteContext on that second context, you aren't actually destroying the FBOs you created, since they still exist to the first context.

After that point, as I mentioned, ExitProcess gets called, and that calls into our DLL to notify us that the app process is about to detach. Our bug/problem here is that we try to do some cleanup here, when we shouldn't be. When ExitProcess is called, MS recommends doing nothing, and letting the OS clean up. We had been trying to clean up before, and it had worked out ok for the most part, but in this case, there was some stuff with cleaning up the FBOs and some threads that didn't play nice (we were looking for stuff that got annihilated by ExitProcess before calling into our DLL). We'll get this bug fixed.

On your side, you can remedy this for yourself by just deleting all contexts you created during your exit time, instead of just the second context. Or, you can not call wglShareLists if you don't plan on actually sharing resources. I didn't see your sample app ever use the first context. That may not be indicative of your real life usage though.

BTW, I don't think your nobug.exe app is correct. I think it was working because it might have been crapping out without you catching the exception (or maybe because you called glDeleteFramebuffers while handling another exception). It calls glDeleteFramebuffers by passing the FBO name directly in as a parameter, when it should be passing in a pointer to the FBO name. So when you tried to delete FBO 8, the app is doing this:

glDeleteFramebuffers(1, 8);

When it should be doing this:

unsigned int name = 8; // I'm just plugging this in here
glDeleteFramebuffers(1, &name);

Let me know if deleting that other context/not sharing does the trick for you.