Vertex array corruption

Okay so I have encountered a problem. I have two functions

Update()
//deletes old vertex arrays,
//recreates them again with new data

Draw()
//draw the vertex arrays using glDrawArrays

The problem is I am often getting crashes
in the code that delete the vertex array in
Update.

Normally things seem to go okay, but then
ocasionally I get a crash. I believe the problem is occurring because of this

Debugger w/ breakpoints
->CALL Draw
->call glDrawArrays() //I think,
->without Returning from Draw, CALL delete
crash

I had some timer code which generated auto refreshes. I disabled it.

I also did this

//elsewhere on init
CRITICAL_SECTION sect;
InitializeCriticalSection(&sect);

Draw()
EnterCriticalSection(&sect)

LeaveCriticalSection(&sect)

Update()
EnterCriticalSection(&sect)

LeaveCriticalSection(&sect)

Any suggestions?

This question has a lot to do with elementary debugging skills, and very little to do with OpenGL.

OpenGL copies the data you draw when you call DrawElements() (and DrawArrays(), etc), unless you’re using the VertexArrayRangeNV() extension. In neither case does OpenGL delete or free any memory you pass to it. In fact, it may be linked against a totally different runtime library than you are.

I suggest looking for overruns, or stale pointers, or other such memory corruption issues in your code that deals with vertex arrays.

Also, as a word of advice: deleting and re-creating a block of memory takes time. Overwriting an existing block with new data is faster. Thus, allocate a maximum-size block up front, and re-use it, for better performance.

Thanks. Memory corruption is not the problem.
I have checked my code for such issues(special app). I was simply trying to see if I had overlooked some issue, or querky behavior of glDrawArrays.

As for rudimentary debugging, I think not.
Debugging is not rudimentary nor easy in a multithreaded enviroment. Add to it the fidgity problems encountered w/ opengl + multithreading. However, as I believe I have taken care of that issue, it is not important. I simply pointed it out for the sake of completeness.

As for opengl, depending on the drivers, platform, I have found it suffers through a number of problems with state management, and often unrelated attributes affect each other even though they are not directly connected.

If anybody has some ideas, or has experienced any issues with glDrawArray please post it in this thread. Thanks in advance.

Originally posted by jwatte:
OpenGL copies the data you draw when you call DrawElements() (and DrawArrays(), etc), unless you’re using the VertexArrayRangeNV() extension.

It thought I could mention that I wouldn’t rely on OpenGL always copying the data. Specially if the array is big, it may make more sense to lock down the user memory (it will take less time than copying it, so you will avoid starving the graphics chip) and DMA directly from there. Obviously the convenience of doing that depends on your workload and application profile (CPU, transfer or otherwise GPU limited).

If the driver has a wait for command completion missing after the DrawXXXXX rendering, you could encounter the kind of problems he mentions.
If the problem is fixed by adding a glFinish() after the draw call, it’s more than likely that it’s this scenario.

Besides the NV case you point out, another case that benefits from not copying the data is when the array has been “locked” (this is a different lock from before) by using Compiled Vertex Arrays (Quake3 anyone?).