In what way are the "Use of uninitialized memory" errors that Bounds Checker is pointing out, incorrect?

I don't think pure OpenGL and DirectX would crash like that. Maybe a third-party wrapper would, but those two are tested very well.

Put some print statement at the start of each call, and see what's happening before it crashes. Print out variable values as well in important parts of the code. Write everything to a text file (make sure to fflush() so that everything is written before the crash). Then run diff to see where the outputs from the debug and release versions differ. (Of course you'll need the same random seed, etc.)

Once you find the general area, if you're still not sure what the problem is, comment out various parts of the code until the problem stops.

[edited by - Matei on May 25, 2004 8:23:42 AM]

quote:In what way are the "Use of uninitialized memory" errors that Bounds Checker is pointing out, incorrect?

Check the following code. It''s purely illustrative.

char* block = malloc(4096);memset(block, 0, 4096);for (int i=0; i<4096; i++) {  // do something with block<br></font><br>}<br></pre><!–ENDSCRIPT–><br>Now boundschecker would tell me that somewhere random in the range 0-4095 there''s usage of unitialized memory (where the pointer it specifies points to somewhere inside ''block''). Since the entire block is ''memsetted'', this is pure nonsense. At least as far as I can tell <img src="wink.gif" width=15 height=15 align=middle><br><br><BLOCKQUOTE><SPAN CLASS=smallfont>quote:<hr HEIGHT=1 noshade><br>I don''t think pure OpenGL and DirectX would crash like that. Maybe a third-party wrapper would, but those two are tested very well.<br><hr height=1 noshade></SPAN></BLOCKQUOTE><br>Exactly, and I do not blame these libraries (that''s why I simply said ''external library'' in my opening post). My renderer engine is a wrapper around OpenGL and DirectX, but even in there I do not expect the error to be. I suspect some serious stack/memory corruption somewhere. A call to free which shouldn''t be happening, or something similar.<br><br><BLOCKQUOTE><SPAN CLASS=smallfont>quote:<hr HEIGHT=1 noshade><br>Put some print statement at the start of each call, and see what''s happening before it crashes. Print out variable values as well in important parts of the code. Write everything to a text file (make sure to fflush() so that everything is written before the crash). Then run diff to see where the outputs from the debug and release versions differ. (Of course you''ll need the same random seed, etc.)<br><hr height=1 noshade></SPAN></BLOCKQUOTE><br>I''ve done something like that. Just debugging to where the problem occurs. Normally that helps me with fixing the problem. But here it would for example crash in a call to glColor3ub, while all the data that that function receives is correct.<br><br><BLOCKQUOTE><SPAN CLASS=smallfont>quote:<hr HEIGHT=1 noshade><br>Once you find the general area, if you''re still not sure what the problem is, comment out various parts of the code until the problem stops.<br><hr height=1 noshade></SPAN></BLOCKQUOTE><br>Yeah I''ve done that as well. But while I know the problem shows up somewhere in the renderer engine, I have to comment out stuff that''s totally unrelated to the renderer engine if I want to crash not to occur. I really am flabbergasted about this one…<br>   

You can get a spoofing DLL for D3D (thats probably the wrong name, but anyway...). You put the DLL in your applications directory (its called d3d9.dll) and your app will use this DLL rather than the ''real'' D3D dll. The spoofing DLL just makes calls to the readl D3D library.
If you compile the spoof DLL in debug mode, you''ll be able to see what functuion the crash occurs in, and you''ll be able to check the parameters and stack in the debugger.

think about "uninitialized variables"

does the problem occur only on your machine or have you tested it somewhere else? maybe it is a kind of weird hardware/driver problem?

quote:Original post by Marc aka Foddex

quote:In what way are the "Use of uninitialized memory" errors that Bounds Checker is pointing out, incorrect?

Check the following code. It''s purely illustrative.

char* block = malloc(4096);memset(block, 0, 4096);for (int i=0; i&lt;4096; i++) {  // do something with block<br></font><br>}<br></pre><!–ENDSCRIPT–><br>Now boundschecker would tell me that somewhere random in the range 0-4095 there''s usage of unitialized memory (where the pointer it specifies points to somewhere inside ''block''). Since the entire block is ''memsetted'', this is pure nonsense. At least as far as I can tell <img src="wink.gif" width=15 height=15 align=middle><br><hr height=1 noshade></SPAN></BLOCKQUOTE><br><br>Boundschecker usually isn''t wrong about things like these, how about posting the complete code that it complains about?<br><br>   

quote:Original post by Marc aka Foddex
When I do a full Release compile, the program crashes at some point (somewhere *inside* a external library function call). When I do a full Debug compile, the program does *not* crash at all.

This is typical. In debug builds no code is optimized, so you have lots of extra space in the binary. If you then overwrite some memory, such as writing too many elements into an array, it''s likely that the overwrite will be into some unused memory, so it won''t cause much problems. In release builds however, all your data is more packed, so if you overwrite something, it will most likely destroy something else and eventually cause a crash. This is probably what you''re experiencing.

quote:Original post by Marc aka Foddex
This ofcourse is very annoying, since in Debug mode you can at least debug!

Actually you can debug release builds, it''s just a bit more annoying as much code will be optimized away. Make sure to enable debug symbols for your release builds, it''s described here: http://www.codeproject.com/debug/survivereleasever.asp


A more useful tool, but way more complex to use, is PageHeap. PageHeap is a free tool from Microsoft.

Be aware that it''s rather complex to learn, no fancy UI etc.

I would recommend starting on a simple project, such as an "hello world" application, so you can learn how to debug a release build, generate symbols and fake memory overwrites. Once you understand how it works, go to your real project.



http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ddtools/hh/ddtools/gflags_4n77.asp?frame=true

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q286470

YES!

Finally, finally, finally, after weeks of headaches, I found the solution to my problem! A nasty little bug it was, I had to move one line of code in order to fix it, but since the fix no crashes have occured!

For those who are interested: My project has an abstract renderer class, implemented for both OpenGL and Direct3D. In that way coding for either library is very easy. The functions involved were:

SetMultiTextureLevel - set the amount of textures for each face
SetArrayData - set strided array data for vertices/normals/texture coordinates

The function SetArrayData checks the multi texture setting to determine how many texture coordinate texture pointers need to be set (using glTexCoordPointer in OpenGL). The problem with my code was that SetMultiTextureLevel was at one point being called AFTER SetArrayData. This is ofcourse a possible bug situation:

- suppose the MTL is set to 1
- then SetArrayData is called, setting the TexCoordPointer for one texture
- then SetMultiTextureLevel is called, setting the MTL to 2
- then some draw function is called

What''s wrong now? The problem is that the texture coordinate pointer for the second texture level isn''t set. In stead, some old setting for the second texture level is used. This ofcourse *can* cause problems! One ASSERT to assure SetMultiTextureLevel is never called after SetArrayData and these problems won''t occur again w00t!



Hopefully anybody understood what I just tried to explain

Congratulations. The only feeling more intense than the frustration of a bug you can''t find is the feeling you get when you expose and fix it.