Problem with OpenGL and current NV driver

[cmaster.matso]

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



Regards,
MK

[Dark Photon]

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]

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]

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]

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

[mhagain]

Using a custom Windows theme?

[cmaster.matso]

Yea? Does it matter?

[cmaster.matso]

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

[cmaster.matso]

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]

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.