I have written some skinning/animation code, I have a per pixel fragment shader and a skinning vertex shader. My code works on some of my models, but I have bugs which cause a bluescreen.
Sometimes the “crash” is reported to be inside nvogl.dll. In other occasions the program renders a few frames correctly, then continues to run but stops rendering, and produces a blue screen when my code tries to close the window (on exit).
the shaders seem to compile and load ok (at least they work for 6/10 of the models I use for testing.
glGetError() reports no errors at all. Is there another error checking function for shaders?
If you could suggest any debuging ideas, or tools I could use it would be helpful
P.S I work on a dell inspiron with geforce go7800 and on a desktop with geforce 5600. On the desktop the problems I get are somewhat fewer. The dell drivers are a bit old, and the new geforce drivers refuse to install on my laptop.
I don’t recall exactly how, but there are good ways to debug bluescreens. You can connect your PC to another with a NULL-modem cable and catch the error. You have to put the PC running your OpenGL app (host) into debug mode.
This is quite a lot of work to configure, but provides much information. You might as well try to see what the bluescreen reports and see if that could somehow match a mistake in your code.
I wouldn’t recommend to try to debug blue screens. You should first debug what case in your application triggered the simpler user mode crash inside the OpenGL driver.
Try to isolate the last OpenGL command you did which triggers the crash. Just catch it in the debugger and see if you can see a stack to your app. If not, you could try the OpenGL debugging tools glIntercept or gDEBugger to trace the commands (google for them).
If the crash is on anything related to vertex arrays (sizes, enables?), DrawElements indices (out of bounds?), or pixel/texel data (alignment?), check these for consistency.
There must be no out of bounds accesses whatsoever.
If that doesn’t help, try to isolate the case to the least minimum reproducer (sometimes that helps to find app problems as well ;-)) and let someone from NVIDIA know about it.
You can “hack” the drivers .inf file to make it install on a notebook. Just take the old driver, find your device ID and add those lines to the .inf file of the new driver. You have to add lines in two sections.
It can be very hard to track the problem. I’ve had that happen with the “other” API
_open
_write
_commit
_close
The above function are used to force writes to file so if the blue screen happens, you will have a report. Also, it will slow down your machine by a lot because it forces writes to disk.
I ran into a bug in Visual Studio 2005 C++ stuff on WindowsXP SP2 where opening a file using iostreams in binary mode would cause any unix-style line-ending characters to be converted to windows-style (and this is binary mode!). Needless to say, it broke things rather horribly. I don’t know if this applies to other windows versions, VS versions, or whether it was a debug/release issue, though. You might want to dump any data you read from a file so you can compare it manually, though.
The crashs in the nvoglxxx.dll normally come from using buggy/wrong pointers when setting up vertex data and drawing primitives or by specifying wrong parameters for these calls (glVertexPointer/glDrawRangeElementsEx/…).
Changing state and other things like activating texture units should not break the driver, so the calls to be examined are the actual drawing calls.
Using try/catch blocks around these calls together with assertion tests hopefully helps you identifying the problem (check the parameters, …), since a user defined breakpoint will be called and you actually can debug something.
If the call itself seems ok but raises an assertion, then you probably messed up the pointers to the actual vertex/texcoord/… data earlier in your code. Check the declaration/offsets/… of your data and you should be able to track down the bug.
I’m talking of something like this (normally only useful in debug configuration because of the slowdown, hence the #ifdefs):
#ifdef _DEBUG
int iDriverException = 0;
try
{
// gl draw calls go here
}
catch(...)
{
iDriverException = 1;
}
assert( iDriverException == 0 );
#else
// gl draw calls go here
#endif