Today, I myself, came across this problem as well. I know this post is old, but when googling this problem myself, this thread came up. And I didn’t find anything out there to answer my question, I just ended up finding the answer myself by comparing my code to code I already written. But in hopes if any one ever has this issue again, I thought I’d point out a reason this could happen (And a common mistake):
It could very well be a possible bug. But probably not since it does make sense that one should do this every time.
When you go to use the buffer, you had to have called glEnableClientState(GLenum Array) to enable the array the buffer is used for.
This enables the pointer to the buffer, for the array in your OpenGL context to use. But did you call glDisableClientState(GLenum Array) for each of the ones you enabled?
Failure to do so will cause:
when using glDeleteBuffers the deletes appear to happen successfully, but later when a call to various openGL functions will cause a deep rooted access violation (Null pointer violation) in nvoglv32.dll
I find it best practice to use glEnabledClientState() immediately after the binding to the buffer it will be using, then glDisableClientState() immediately after the call to glDrawElements()
This way you avoid having this problem in the future.
Hope it helps!
As for it being a bug or not.
This problem is reproducible, but always appears to be from different causes, because it always happens later in it’s own thread. But the root of the cause is definitely the call to glDeleteBuffers without making the call to glDisableClientState() to any Arrays that are still associated to the buffer.