Problem with OpenGL and current NV driver

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’?

[ATTACH=CONFIG]216[/ATTACH]

Regards,
MK

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.

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

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

I run my application with DrMemory and got the results (HUGE FILE)

Using a custom Windows theme?

Yea? Does it matter?

Can such problems be caused by other driver problem, like sensorsview?

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’?

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.

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.

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 :confused:

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.
When I changed theme to ‘Windows classic’ nothing changed - error still occures…

After changing the theme to ‘Windows classic’ error still occures…

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

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.