It came out of nowhere - I can’t recall I made any relevant change in code that provoked this behaviour.
Here it is:
in Release build of my app (Visual 2005) the function:
glDrawElements(GL_TRIANGLES, indices_count, GL_UNSIGNED_INT, indices);
breaks the application.
In Debug build it works OK.
I can get it working in Release build by reducing the value of indices_count almost by half, but then only part of the model is drawn.
How it breaks the application?
Check that you are allocating correct ammount of memory or that your arrays have correct sizes corresponding to parameters you give to the OGL. For some inspiration about what might go wrong you can look here
thanks for the link Komat, I’m reading it just now.
The error:
when I turn on run-time debugger, it says:
“Unhandled exception at 0x69729682 in rem.exe: 0xC0000005: Access violation reading location 0x00d94000.”
The arrays and their sizes have virtually no chance of becoming corrupt - they are just loaded from file and do not change. And I’m able to avoid crashing and draw part of a model when I decrease indices_count to about 40% of its original value - but then only that 40% part of a model is drawn.
Of course there is always a chance that the cause of my problems is my stupid mistake in some other part of the code. OK. I get back to reading.
I run into this problem too.
Try to checkout, what maximum of indices glDraw(Range)Elements can handle (draw range elements). I think, you have more than 32000 or 65000 (15/16bit limit) indices/vertices.
This problem occurs often with professional cards (FireGL- or Quattro-Cards).
Setting the opengl-profile of the driver to “OpenGL-Games” solves this problem. What I dont understand is, why the driver crashs so hard, this is absolutely not acceptable.
Most application don’t use more than 65536 indices (I think this is a object limit in 3D-S-MAX too).
Some times ago, I read some optimisation tips, using 16bit indices should be more performant than 32bit int indices… .
In my applikations, I’m using 32k indices-splitting to workaround this bug.
Heady: the number of indices is about 20 000 so this should not be a problem.
Instead of chasing this bug I kept on working with the debug build on some sound library integration and after that I made another release build and it works! the crash just disappeared!
Originally posted by therealremi:
Instead of chasing this bug I kept on working with the debug build on some sound library integration and after that I made another release build and it works! the crash just disappeared!
It is likely that memory layout changes caused by additions to program simply masked the original problem. It will probably demonstrate itself again someday, maybe in different way and different place.
Can this crash have something to do with the fact that in one draw function I enabled and used 4 texture coordinate arrays without disabling them at the end of the function, while in another draw function I enabled and used only 2 texture coordinate arrays?
The crash returned and the debugger always pointed at glDrawElements() so I put glDisableClientState() commands at the end of every drawing function and it seems to be working now. Or the bug is still masked out by the changes to the code.
If an array is not disabled, it remains enabled 
I guess it is your mistake. Really, the array API is a bit messy, I hope Longs Peak will correct this issue.
Originally posted by Zengar:
If an array is not disabled, it remains enabledI guess it is your mistake.
Yes, by “bug” I meant my mistake, not the driver’s.
It seems that 4 arrays were enabled and then, in another drawing call, only 2 arrays were specified so I guess the 2 arrays from previous call were used but their size was to small and this caused memory access crash.
I wish there was some way to debug this kind of errors.