ProTools/AAX OpenGL nvoglv64.dll Crashes

#1

Hello,

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?

Thanks

#2

FWIW I have crashes in nvoglv32.dll as well but I just need to launch the new demo app, go to GL demo and change the shader preset.

Win 7 GeForce GTX 650 and and driver 320.49 which I downloaded a couple month ago.

Will check with latest driver FWIW

 

So your issue in maybe not related to AAX at all.

 

#3

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.

#4

Still hapenning with latest nvidia driver FWIW

If you got some hints how to trace the error, I can check.

#5

If there's a sensible stack trace I'd be interested, but not sure how else you could debug this sort of thing.

#6

Unfortunately the stack trace contains only the nvidia driver :(

#7

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.

#8

Can I check where the detach should go? Its in the destructor of my class that uses openGLcontext and inherits openGLrenderer.

Yes, that sounds right.

#9

Use a FileLogger to create a runtime log

Rail

#10

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.

 

#11

Ah, dodgy GL drivers. A stack trace would be helpful, but there may not be anything that could be done to fix it if there's a driver bug.

#12

hope this helps! 


>    nvoglv32.dll!583ef6c3()    Unknown
     [Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]    
     nvoglv32.dll!5848a9b2()    Unknown
     nvoglv32.dll!5848add2()    Unknown
     nvoglv32.dll!58481ca3()    Unknown
     nvoglv32.dll!57bbd4ed()    Unknown
     nvoglv32.dll!58226c8a()    Unknown
     nvoglv32.dll!583b3a8c()    Unknown
     nvoglv32.dll!5833dde7()    Unknown
     nvoglv32.dll!5833d72d()    Unknown
     nvoglv32.dll!583afb83()    Unknown
     nvoglv32.dll!583b15f1()    Unknown
     nvoglv32.dll!57b18745()    Unknown
     nvoglv32.dll!57b224fc()    Unknown
     nvoglv32.dll!57b2b0f1()    Unknown
     nvoglv32.dll!57b0f191()    Unknown
     nvoglv32.dll!5833dde7()    Unknown
     nvoglv32.dll!583b3a8c()    Unknown
     nvoglv32.dll!5833dde7()    Unknown
     nvoglv32.dll!583b3a8c()    Unknown
     nvoglv32.dll!583ea51b()    Unknown
     nvoglv32.dll!5849d756()    Unknown
     nvoglv32.dll!57b25a06()    Unknown
     shell32.dll!763552e1()    Unknown
     nvoglv32.dll!57b07a81()    Unknown
     nvoglv32.dll!57b0915e()    Unknown
     nvoglv32.dll!583af4d8()    Unknown
     nvoglv32.dll!583af8a9()    Unknown
     nvoglv32.dll!57b0eb29()    Unknown
     nvoglv32.dll!5837cf59()    Unknown
     nvoglv32.dll!5833dde7()    Unknown
     nvoglv32.dll!583b3a8c()    Unknown
     nvoglv32.dll!5822f2cf()    Unknown
     nvoglv32.dll!57a448f3()    Unknown
     nvoglv32.dll!57a44458()    Unknown
     nvoglv32.dll!581a611f()    Unknown
     nvoglv32.dll!5813e873()    Unknown
     nvoglv32.dll!5811afa0()    Unknown
     nvoglv32.dll!5822995b()    Unknown
     nvoglv32.dll!58229799()    Unknown
     nvoglv32.dll!5833e97b()    Unknown
     kernel32.dll!76ff495d()    Unknown
     ntdll.dll!777e98ee()    Unknown
     ntdll.dll!777e98c4()    Unknown
 

#13

Not exactly full of clues, is it!

The only info it gives is that something is going wrong very deep within the GL driver, so probably a driver bug.

#14

the problem happens in my updateshader function. I will try to fix it today and let you know. Jules u are awesome!! thanks for the quick feedback

#15

7ser23: any updates on your attempts to fix it?

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?

 

#16

If it's any help, here's the stack trace of the "OpenGL Rendering" thread during the crash, after changing shaders in Juce demo.

Note that this isn't the thread where the crash occurs but it is in a driver call so possibly this invokes the other thread to crash:

(am working at a friend's home where she has a Windows 7 with Nvidia setup)

#17

Not much help, unfortunately - definitely looks like a driver bug.

#18

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.

#19

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!

#20

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..).