glDeleteTextures() throws "An invalid HANDLE was specified"-exception C0000008

I’m kinda ashamed to ask this question, but:
In one of my projects, during the cleanup-routine, glDeleteTextures() throws the exception mentioned above IF running it from within Visual Studio - that is no glError is generated nor does the program crash or something if run outside the IDE. If simply clicking “continue” everything seems to go well. Note the above is a windows-exception, not a glError.
I’ve spent some time trying to reproduce it in test-cases but this does not seem so easy. Even when calling DeleteTextures with trash-values nothing special happens. The strange thing is that quite a few textures get deleted during the cleanup and only one or two trigger that exception, so I doubt I’m doing something wrong methodically. I’ve tried to verify the texture-ids passed to glDeleteTextures: I’ve checked for double-ids and I even drew each texture in full-screen before calling the cleanup-routine to have a look if the ids are okay: They are all there.
I’ve to say I don’t have the slightest idea what could trigger the exception.
Does anyone have an idea?

Thanks in advance,

Just for information: The problem disappeared. Not that I did change anything that should have solved this…
This somehow leaves a bad taste.

Do you delete textures before or after destroying your window?

Before as destroying the window would destroy the rendering-context the textures live in I guess. The exception popped up once or twice again since it seemed to be gone. This is quite mysterious. Note that I did come to writing a cleanup routine because of the very same exception being thrown by the driver when simply calling exit() or destroying the rendering context without deleting anything myself. My guess was the OS would handle the cleanup correctly (and it did, I guess - the exception doesn’t do anything outside the IDE).

Sounds like you’ve a wild pointer then.

Dunno - what do you mean? Is it possible that the DeleteTextures-call triggers something else that leads to the exception (like the driver shifting around stuff because some mem got freed)? The exception appears in the controlled cleanup-Routine. This is what is making me scratching my head.


HANDLE in this exception is a Windows API data type, and the fact that the exception is being thrown with seeming randomness indicates that the problem is not at the glDeleteTextures call but somewhere else. One thing that can cause this is a bad pointer leading to a corrupted return address leading to execution jumping into the middle of a function where it has no business being.

Have you tried running this in a debugger?

No, that beast was thrown somewhere deep in nvogl. Seemed all right. Doesn’t even do anything except open up the exception handler built into the IDE.

Breakpoint before the glDeleteTextures call, breakpoint after it, inspect variables, including your HDC, your HGLRC and the texture name to be deleted.

That won’t lead anywhere I guess. Despite the fact that it would likely take 10000 “continue”-clicks to catch the exception, now that it suddenly seems to have fixed itself. No - those pointers are all right. If something was wrong context-wise I’d have catched that later on.

What we’re actually interested in is comparing the call stack before the exception occurs with the call stack after the exception occurs. That will tell you if execution jumped to somewhere it shouldn’t have.

That would really be a hard issue. Sadly I cannot reproduce the exception anymore. But my thought would be that if the stack got messed up the program flow would not be normal afterwards. The cleanup-routine has some local variables which would have been messed up then resulting in an access Violation. The this pointer of the objects always looked normal at the time of exception. No bad vftable, no member-variables containing rubbish, normal program execution after the exception. If I remember right the exception was thrown in another thread of nvogl. Not in the main thread of the program.

I cannot help myself but assume the impossible: My program generates that same exception in a totally unrelated-to-OpenGL context when messing around with the console and stderr (that’s an issue for itself) in a more-or-less controlled manner. The nvogl surely would not contain any references to those standard streams, wouldn’t it?

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.