Every 10 times or so, when I run our game, it crashes on a draw call after we load our textures and start trying to load the normal game screen. (Rendering the initial loading screen doesn’t crash)
The actual error is:
First-chance exception at 0x69CCA3E0 (nvoglv32.dll) in nightmareDebug.exe: 0xC0000005: Access violation reading location 0x007C0008.
It is crashing on a call to glDrawArrays. We are not using any sort of buffers for this particular call - just a standard glVertexAttribPointer. We do a glGetError with pretty much every operation, and it’s not detecting any errors. I’m a bit stumped as to what could be going wrong. I looked at the verts that it is trying to draw, and they seem fine.
Any idea what the problem might be or how I should go about fixing this error?
Thanks!
Access violations during glDrawArrays or glDrawElements are most often due to incorrectly enabled vertex attribute arrays.
Please check your current state of the enabled vertex attributes very carefully. One which is left enabled inadvertently without providing any or enough data will result in these kinds of errors when sourcing data out of bounds during the draw call.
If that’s not it, maybe there is some problem with memory consumption. You’re running a 32-bit app according to the DLL name. Does the same thing happen in a 64-bit version?
I looked it over carefully, and it seems like the vertex attributes are all set up correctly. This geometry has 1 vertex attribute, and it should be calling glDisableVertexAttribArray on the other ones enabled.
Unfortunately, we don’t support 64 bit, so I can test there.
Any ideas on how I can track this down?
Thank you for your help! :)
Since this isn’t a solid reprodcuer, it could be anything like scribbling over memory when loading data, different code paths taken with sideeffects, driver bugs, etc.
I fear you’d need to isolate that further inside your application and get this to reproduce more reliably first before you could use some OpenGL API tracing/debugging tool to analyze the error condition state.
I don’t have any ideas how to isolate this further. I can re-run with the same source data, and it won’t crash. It happens in both debug and release. One would think with the debug heap, it would produce different results if it were a random memory thing.
The code path isn’t changing because this is before any user input is processed, so I am at a loss. I hate to point fingers at the driver before I am positive there are no bugs on my end, but I am having trouble imagining what sort of bug it could be on my end.
Hi,
we are also having this problem. Exept we use a 64bit application and the crash happens in nvoglv64.dll.
It happens very randomly so we cannot track this futher down.
The last time it happend on a system using driver version 9.18.13.2762 and threw out the error:
Unhandled exception at 0x6d8ccc9a in nvoglv64.dll: 0xC0000005: Access violation reading location 0x000007fe00000013.
Entering this problem in Google reveals that hundreds of people are facing the same (or almost the same) problem, but nobody knows (or posted) a real solution for this.
Is there anything I can do to fix this issue, exept of installing a newer driver and pray that this issue won’t happen again?
Best regards,
Marcel
Access violations in user address space can be anything so there is no “this issue” to be fixed for that class of errors without a solid reproducer.
The reason you’ll find so many of these is that it’s one of the easiest things to get wrong.
Most often these turn out to be application errors, but even a single flipped bit in memory would be enough. Memory errors, flaky power supplies, basically anything could be the root cause for this when it happens only seldom.
If you have done everything in your application to make sure the OpenGL stream and other data accesses are not the root cause for your access violation case, there is really nothing else left than to test newer drivers.
In your case there are multiple generations of newer drivers available if you saw this most recently on 327.62 which is over a year old
If it still happens on the newest available drivers there would only be a chance to analyze this with a very solid reproducer.
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.
1 Like
I realize that this is an old problem but I have been running some 3D application software that runs quite well on a PC. When I bring it up on a Windows Server 2012 R2 machine with a Tesla K80 GPU on a PCIe Expansion module it runs fine (100% utilization of the K80 at times) until it gets to a specific application that crashes almost immediately on starting. I have installed the latest driver recommended for the Tesla K80 and also the latest GEFORCE driver package available. If I try to install an alternative driver with the recommended fix for this thread, I get a BSOD for corrupt Page Pool Headers or invalid address reference from kernel code. The vendor of the application is not very helpful but I am slogging through it. Is anyone aware of someone having this problem with a Tesla K80 or other?
I had the same problem, I used a couple different ways to try to figure out the cause of the crash.
One way is to run Nsight and let the application crash inside it, save the dump file and inspect it with windbg.exe …
Another way is to use Nvidia Aftermath, download and documentation are on this site …
https://developer.nvidia.com/nvidia-aftermath
Another way, although not necessarily helpful with the crash itself, can give you the execution steps of the application so you might get some idea of what it was doing when it crashed is glintercept.
Good luck.
Thank you, hat is much more helpful than any other response I ever received. I appreciate you taking the time to give me such a detailed response.
In my case there was my mistake in giving proper size
bug in the code
glBufferData(GL_ELEMENT_ARRAY_BUFFER, indices.size() * sizeof(indices)–wrong variable issue here—, indices.data(), GL_STATIC_DRAW);
fixed code
glBufferData(GL_ELEMENT_ARRAY_BUFFER, indices.size() * sizeof(GLuint), indices.data(), GL_STATIC_DRAW);