I'm having a huge headache with breakpoints only showing nvoglv64.dll. This happened originally when closing the GUI window in ProTools (Juce host doesn't appear to have problems), but lately also can happen when I press play in ProTools (I added a 2nd monitor today so more load on nvidia driver?!). The laptop has both an nvidia and integrated intel, it doesn't seem to crash when only using the intel. At first I thought it was because openGLcontext.detach() wasn't being called, but this was added to the destructor of the class that uses the openGLcontxt, which also inherits openGLrendererer. Does anybody have any insight of crashes with nvidia when using openGL in JUCE plug-ins on ProTools AAX 64bit? Did I not put the detach call in the right place?
Yeah, some gl drivers just seem to be downright buggy. I've heard of other people having this problem with the demo GL app, but it works fine on most machines.
Unfortunately with driver bugs, it's hard to know what to do about them.. I'm confident that the juce GL code isn't doing anything silly, but without any clues as to why the driver's crashing, it's impossible to know if there's any workaround that could be possible.
My stack trace tends to show only the nvidia driver. Sometimes it comes up on openGLcontext, after a makeActive... trying to remember. I thought it might have been because detach wasn't being used (correctly). Can I check where the detach should go? Its in the destructor of my class that uses openGLcontext and inherits openGLrenderer.
I tried using gDEbugger attached to ProTools but it comes up that ProTools cannot run attached to a debugger. Its the develope version and I can attach it to VS2012 when I have my plugin project loaded. If anyone has any clues on how to watch for the GL calls within PT then let me know.
Hi I am having the same issues with my own OpenGL application when I am trying to change shaders on the fly. After reading some stuff in the internet (http://stackoverflow.com/questions/15041120/crash-at-draw-call-in-nvoglv32-dll-on-new-video-card) and how the destructor maybe handling the problem, I tried to remove it and nothing.
Also I increase the delay of my shaderlink and nothing.
enum { shaderLinkDelay = 500 };
It is important to mention that my app works perfectly in my laptop with an nvidia card (dont remember which one or the driver) but here in my university it just crashes with a GTX 680 driver version 331.82.
Maybe you also need to know that I run 2 monitors at my house and works with one or the two of them connected, but in my Office with 1, 2 or 3 monitors connected it just doesn't work.
FYI this is the exception I have:
Unhandled exception at 0x54E1F6C3 (nvoglv32.dll) in JuceOpenGL.exe: 0xC0000005: Access violation reading location 0x00000000.
Our users are reporting this issue too but sadly we don't have an Nvidia setup to test it on.. We're thinking about buying a GPU to be able to debug this issue..
plugin_wielder: Which GPU do you have?
This could help us when deciding what to buy..
I see otristan has GeForce GTX 650 and 7ser23 has GTX 680. We also have users reporting the issue with GeForce GT 620 and GeForce 210.
otristan and 7ser23: do you also use laptops with both Nvidia and integrated Intel GPUs like plugin_wielder does?
Of course I believe you and I am pretty sure you are right and that it is indeed a driver bug.
Unfortunately, I can't easily make Nvidia fix the bug so I'll probably resort to working around the bug. Or if I can gather more info on it maybe there's a chance it will actually help Nvidia fix it.
Meanwhile, not sure what the bug is yet, but I imagine the work-around may be adding some sort of synchronization to avoid doing X during Y (just a guess, and I have no idea what X and Y are). This "solution" might be a horrible hack that you may not want to put into JUCE (similar to the Windows+VST+keyboard stuff) but I'd still use it in my branch so that my products will work.
Yeah, this kind of thing is incredibly hard to deal with, because it's so difficult to guess exactly what's making the driver screw up.. If you do manage to get any clues from your experiments, I'd be keen to know!
Just sharing a few more findings in case it helps someone who is also looking at this issue.
As mentioned before, when changing shaders in juce demo, the crash happens while the OpenGL rendering thread is in clearGLError.
If I comment out that clearGLError, the crash happens in another clearGLError. Resuming this procedure, after commenting out 5 crashing clearGLError and JUCE_CHECK_OPENGL_ERROR's, the crash occurs at swapBuffers().
Conclusion: the clearGLError/JUCE_CHECK_OPENGL_ERROR acts as a "flush" for the Nvidia driver which causes it to crash, and the crash happens due to some OpenGL usage which the Nvidia driver can't handle.
So I sprinkled some JUCE_CHECK_OPENGL_ERROR's around the code to see after which OpenGL call the drivers breaks. It happens to be the first glDrawElements inside OpenGLDemoClasses::Shape::draw. Btw, without this glDrawElements call, the program doesn't crash (but doesn't draw the shape either..).
