NVidias Threaded Optimizations: Crash

[henniman]

Hi all,

i had recently some user crash reports. These crashes occurred when the users loaded images, but only when "Threaded Optimizations" were turned "On" or "Auto".

Some more info here
mxwendler.net/Blog.41.0.html?&tx_ttnews[tt_news]=19]

Is it possible that these "threaded" actions tend to crash if the application withdraws the current render context by calling
wglMakeCurrent(MXW_NULL,MXW_NULL)?

best,
hendrik

[jwatte]

No. The Threaded Optimizations are still consistent with the OpenGL specification. I can run my own OpenGL code, and that of others (Quake series, C4 engine, etc) with those optimizations turned on.

If you can create a small test case that causes the crashing, then NVIDIA developer support would probably want to get that, so they can reproduce and fix the problem. However, it's probably more likely that you're doing something that is not actually to spec, and that's causing the crash.

[henniman]

If you can create a small test case that causes the crashing, then NVIDIA developer support would probably want to get that, so they can reproduce and fix the problem.

thats my problem: condensing what causes the problem. its 100% repeatable but really weird, because ...

However, it's probably more likely that you're doing something that is not actually to spec, and that's causing the crash.

its too easy to be slightly offline in gl =) - for this reason i have 3(!) (glintercept,gdebugger,glexpert) independent opengl error checkers regularly running and they all stay calm. plus my own error checking macros. nevertheless it crashes. sigh.

all i see is

a) a crash in a thread not started by me ( gets created when i create a second gl window sharing the main context ) and calling lots of gl:


> 04defda9()
nvoglnt.dll!696ccc25()
nvoglnt.dll!696bfa30()
nvoglnt.dll!696bffcc()
nvoglnt.dll!6952303f()
nvoglnt.dll!696588c1()
ntdll.dll!7c91e96c()
kernel32.dll!7c80b810()
nvoglnt.dll!69727deb()
nvoglnt.dll!697630c0()
nvoglnt.dll!69575880()
nvoglnt.dll!6957afbf()
nvoglnt.dll!6977fdb5()
nvoglnt.dll!6975fd91()
nvoglnt.dll!695e071e()
nvoglnt.dll!6967e45d()
nvoglnt.dll!6962f747()
nvoglnt.dll!6962f86c()
nvoglnt.dll!697280d7()
kernel32.dll!7c80b50b()
kernel32.dll!7c8399f3()


0xC0000005: access violation reading at 0x0824e192

b) always the same call stack location in my application
( ironically when i call glGetError() )


when glintercept is running,
the crash does not occur. any idea?

best,
hendrik

[sqrt[-1]]

With GLIntercept, are you setting the "ThreadChecking" option to True?

Also, if it is not crashing with GLIntercept, you can "daisy-chain" GLIntercept against itself so you can see what OpenGL calls it is making internally.

To do this, create a directory and copy the GLIntercept dll's into it. (Eg. c:\Temp\Testing\ ) Set this gliConfig.ini to text logging and logging from start.

Next, on the main gliConfig,ini in your project set:
GLSystemLib = "c:\Temp\Testing\OpenGL32.dll"

This way the GLIntercept in the "Testing" folder will record all the OpenGL calls made by the first GLIntercept dll.
(If you are dumping OpenGL calls in the main app, you can open the output logs in a "diff" program like windiff to see what the differences are.)

Then, once you know what additional calls are being made, you can start inserting them into your app until it stops crashing. (hopefully - unless it is a thread sysnc bug)

[jwatte]

i create a second gl window sharing the main context

So, that's a clue! If you instead create a second context, not sharing lists, does it crash? Do the two windows share the same window message queue/thread? I assume the crash goes away when you un-check the "Threaded Optimization" option in the NVIDIA control panel?

If your project can be packed up in a zip file and installed somewhere else, you might want to send it as-is (without simplification) to the NVIDIA devrel people. They've seen lots of weird test graphics things and half-baked renderers (including mine), so don't feel ashamed :-) If they can reproduce the crash, they can fix it -- or get back to you, telling you what you're doing wrong.

[henniman]

hi,

after some testing and searching i found that this advice:

---
You can customize the nvidia thread by setting the process affinity to 1 CPU when you create the window & opengl context. Restore it afterwards (use the sysmask)
---

found in this thread
http://www.opengl.org/discussion_boa...&Number=164629

solved the problem.
so it is a driver bug?
i will send a report to devrel@...

@sqrt[-1]: thank you for glintercept. its fantastic! will there be an update? i have one minor wish: en-/disabling it from my application

(eg throuch calling glGetUniformLocatio(0,"intercept_start")

best,
hendrik

[CatDog]

Yes the issue in the quoted thread is a driver bug that appears on dual core systems with Geforce graphics. But there, it's "only" a weird performance thing. If your application *crashes*, it seems to be a new issue.

Anyway, if you can reproduce it, please send it to nVidia! Maybe the two problems are related to each other.

CatDog

[sqrt[-1]]

hi,

@sqrt[-1]: thank you for glintercept. its fantastic! will there be an update? i have one minor wish: en-/disabling it from my application

(eg throuch calling glGetUniformLocatio(0,"intercept_start")

I will probably release a new version with bug fixes I have accumulated, but probably no new features.

If I decide to do a GLIntercept 2 for OpenGL 3, I will see what I can do.