PDA

View Full Version : Problem with OpenGL and current NV driver



cmaster.matso
06-26-2012, 12:49 AM
Hi,
Since driver version about 290.36 (don't rememeber exactly) any OpenGL app I have crashes at the start. Some of them I cannot debug (i.e. RenderMonkey). But debugging my own one I discovered that there is a memory problem about some of the basic functions in OpenGL (I get an info from VS2008 debugger like in the screenshot attached). Is there an issue concerning improper behaviour of OpenGL function like 'IsProgram', 'IsEnabled' or 'GetInteger'?

792

Regards,
MK

Dark Photon
06-26-2012, 04:39 AM
How much stack space are you allocating for the GL thread? Try bumping it up by 2X. Had this issue come up back around 270.x.

Try running a memory debugger such as valgrind to help establish whether/where there's a memory bug.

thokra
06-26-2012, 06:05 AM
The error merely suggests that you're trying to write to a protected area of memory. This can mean you're trying to access memory via a null pointer(function pointer or pointer to data). I assume you don't get proper function pointers for your GL functions anymore, which can happen, for instance, if you can't create a valid GL context. You can verify that easily when using GLEW and trying to access some arbitrary GL functions loaded by GLEW after glewInit(). If it crashes, chances are that you didn't a valid (and current) GL context at the time glewInit() was called. This would also explain why other GL apps don't run - because they can't.

You might just have screwed up your driver installation - although I'm not sure how this still happens under newer version of Windows (it's quite easy to do Linux).

cmaster.matso
06-26-2012, 07:37 AM
If there was a problem with functions pointers none of the calls would succeed, right? But in my case a subsequent call to a certain routine causes the problem described here. I.e. I have a call to 'glIsEnabled' in the rendering loop. First time it executes well, but second causes the mentioned error. It seems that something bad happens within the driver code. Is it possible that some kind of OS failure (not directly related to graphics) can lead eventually to GL driver error? Or can that be a hardware problem (hope not)?

Regards,
MK

cmaster.matso
06-26-2012, 08:07 AM
I run my application with DrMemory and got the results (HUGE FILE (http://mgpi.googlecode.com/files/results.txt))

mhagain
06-26-2012, 08:25 AM
Using a custom Windows theme?

cmaster.matso
06-26-2012, 10:14 PM
Yea? Does it matter?

cmaster.matso
07-11-2012, 12:58 AM
Can such problems be caused by other driver problem, like sensorsview?

cmaster.matso
07-11-2012, 01:10 AM
If it can help - in my OGL app I get error described with following stack trace (from VS 2008):

> ntdll.dll!779d15de()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!779d15de()
ntdll.dll!779c014e()
nvoglv32.dll!5ee72d2d()
nvoglv32.dll!5ee72ed9()
nvoglv32.dll!5ee6287d()
nvoglv32.dll!5ee0e03c()
nvoglv32.dll!5eeb794a()
nvoglv32.dll!5eeb9980()
nvoglv32.dll!5eebb452()
nvoglv32.dll!5eebb686()
nvoglv32.dll!5efa4221()
nvoglv32.dll!5f2c06f1()
nvoglv32.dll!5ef97ba7()
nvoglv32.dll!5ef971b1()
nvoglv32.dll!5ef96f7f()
nvoglv32.dll!5ee0e5a9()
nvoglv32.dll!5ee18b23()
nvoglv32.dll!5ee1af28()
nvoglv32.dll!5ee1d981()
nvoglv32.dll!5efd59da()
nvoglv32.dll!5efd6be0()
nvoglv32.dll!5efd6c1e()
nvoglv32.dll!5ed9a3d2()
nvoglv32.dll!5f0694ac()
nvoglv32.dll!5f0698ed()
nvoglv32.dll!5f306628()
nvoglv32.dll!5f306998()
nvoglv32.dll!5f409024()
nvoglv32.dll!5f40a3ed()
Does it matter that all happens in 'ntdll.dll'?

thokra
07-11-2012, 01:17 AM
This strongly suggests that the driver causes the crash - that doesn't necessarily mean that it's a bug in the driver but that you're doing something that is illegal in the current state. It would be more interesting to see which GL functions provokes this.

mhagain
07-11-2012, 02:26 AM
Yea? Does it matter?
You're getting a lot of "INVALID HEAP ARGUMENT to RtlFreeHeap" from UxTheme.dll - one likely diagnosis is that the theme was always buggy but the older drivers used to swallow the bugs more gracefully. Another is that this particular theme has exposed some bug in the driver that wasn't there before. Either way I'd suggest running without the theme and seeing if it reproduces.

cmaster.matso
07-11-2012, 09:43 AM
The call on which the execution crashes is:
glGetIntegerv(GL_MAX_TEXTURE_UNITS, &n);The funny thing is that this is a second call to the routine done in one rendering loop :/

cmaster.matso
07-11-2012, 09:51 AM
You're getting a lot of "INVALID HEAP ARGUMENT to RtlFreeHeap" from UxTheme.dll - one likely diagnosis is that the theme was always buggy but the older drivers used to swallow the bugs more gracefully. Another is that this particular theme has exposed some bug in the driver that wasn't there before. Either way I'd suggest running without the theme and seeing if it reproduces.
After changing the theme to 'Windows classic' error still occures...

cmaster.matso
08-11-2012, 01:11 AM
This strongly suggests that the driver causes the crash - that doesn't necessarily mean that it's a bug in the driver but that you're doing something that is illegal in the current state. It would be more interesting to see which GL functions provokes this.

Problem is that it also occures when I open an OpenGL workspace in RenderMonkey...