Archived

This topic is now archived and is closed to further replies.

Marc aka Foddex

Debug/Release mayhem

Recommended Posts

Hi all, I have a terrible problem. Why is it terrible? Because it''s so damn hard to find what''s causing it! Let me explain. I''m working on a BIG application. 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 ofcourse is very annoying, since in Debug mode you can at least debug! I''ve tried running my application with the BoundsChecker tool. It comes up with some completely incorrect "Use of uninitialized memory" errors, and eventually crashes itself!! So the debugger crashes on my application, woohoo. My program is totally ''clean'', I''m nearly 100% sure of that. When I still was able to debug my program and actually have it exit normally, BoundsChecker reported no memory leaks or whatever. So no weird Free call or something. I''ve been fighting with this problem for more than a month now. I can''t fix the bug. It''s driving me crazy. Does somebody have any ideas, suggestions, hints, tips, anything? BIG REWARD OFFERED! Whoever gives the ''golden tip'' will end up on the Contributers list!

Share this post


Link to post
Share on other sites
kulik    102
I also got this problem. Some procs crashes when compiler optimize them. Try to switch off optimizing. It helped me. Or play around settings in Linker tab.

Share this post


Link to post
Share on other sites
H0bbes    127
hi.

in your big program you hasn´t threads, or process. The problem that you report is like that you have some threads without synchronized, and in the faster execution(pc) the threads maybe cause dead lock, and when you do debug a program the time slice end and give oprtunity to another thread to run, with threads do debug with printlines is better.

i hope so that help you

[edited by - h0bbes on May 25, 2004 6:04:09 AM]

Share this post


Link to post
Share on other sites
H0bbes: no, my application does not contain threads. I''m experienced with the problems that can occur when one uses threads, and that''s why I only use them when there''s really no other way. But in this case, there are no threads - aside from the main thread ofcourse

Share this post


Link to post
Share on other sites
zppz    226
put logging calls in until you are blue in the face... find the last point your app was in control before the crash.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
"(somewhere *inside* a external library function call"

what excactly do you mean by that? perhaps you have accidently used the wrong version of a library? or mixed multithreaded with singlethreaded libs? and what''s the name of the library?



Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Make sure you have not added lines like this...


ASSERT( functioncall(...) );

anywhere in your program, as these will be completely compiled out in release.

Share this post


Link to post
Share on other sites
The "external library" is OpenGL or DirectX. But my calls to OpenGL are just fine, I know that. Because when I use the Direct3D version of my engine, it crashes in a similar DirectX call. But the data these functions receive is just fine as well. So I guess the memory is invalid (freed to early or something).

And ASSERT's like that do not occur in my app

[edited by - Marc aka Foddex on May 25, 2004 7:29:33 AM]

Share this post


Link to post
Share on other sites
quorn    145
compare with a previous version of the code which doesn''t exhibit the problem as look at what the differences are.

Are you deliberately supressing any compiler warnings? Or have done anything to force it to compile and link?

What is the external library? How do you know that''s where it''s crashing? Expand, please.

You can compile release with debug info too. Try that.

Share this post


Link to post
Share on other sites
quote:
compare with a previous version of the code which doesn''t exhibit the problem as look at what the differences are.

Unfortunately, the program is so big (consisting of two huge static libraries and the main program), it''s impossible to determine since when the problem occurs. And I don''t use CVS, too. Maybe I should''ve... :-/

quote:
Are you deliberately supressing any compiler warnings? Or have done anything to force it to compile and link?

I''m not surpressing any compiler warnings if you mean #pragma statements. I''m an experienced coder, I know when to use them and when not

quote:
What is the external library? How do you know that''s where it''s crashing? Expand, please.

OpenGL and Direct3D, mentioned earlier

quote:
You can compile release with debug info too. Try that.

Hmm haven''t thought of that! I''ll try that!

Share this post


Link to post
Share on other sites
quorn    145
In what way are the "Use of uninitialized memory" errors that Bounds Checker is pointing out, incorrect?

Share this post


Link to post
Share on other sites
Matei    190
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]

Share this post


Link to post
Share on other sites
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[i]

}

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

quote:

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.


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.

quote:

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


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.

quote:

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.


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

Share this post


Link to post
Share on other sites
Evil Steve    2017
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
think about "uninitialized variables"

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
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?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
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[i]

}

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



Boundschecker usually isn''t wrong about things like these, how about posting the complete code that it complains about?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Haytil    525
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.

Share this post


Link to post
Share on other sites