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!

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.

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]

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

"(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?

Make sure you have not added lines like this...


ASSERT( functioncall(...) );

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

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]

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.

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!