How do you handle such cases?

[ninja9578]

I'm hunting down a bug right now which causes my program to catastrophically crash. None of my asserts are failing, if I turn on logging to figure out where the crash it, it doesn't. It also doesn't crash when running in the debugger.

How do you handle situations like this? I'm not sure why the slow down caused by either logging or the debugger causes the program to work correctly, thought it was threading, but I checked the code, there is only one worker thread running when it crashes. And the main thread doesn't do anything other than dispatch messages.

[Lindley]

Valgrind, using both memcheck and the helgrind multithreaded debugging tool. Be aware that helgrind can generate false positives, but it's still sometimes useful.

[Paul McKenzie]

I'm hunting down a bug right now which causes my program to catastrophically crash. None of my asserts are failing, if I turn on logging to figure out where the crash it, it doesn't. It also doesn't crash when running in the debugger.

Is this Visual C++ you're using? If so, then what you can do is start the program normally, and then in Visual Studio, just do an "attach to process", pointing to the program you've started.

If the crash occurs, the debugger will then pop up, and you can inspect from there what the problem may be by inspecting the call stack. You will need to have built the program with debugging information if you want to see the source code.

For Windows, a better long term option is to generate a crash dump, so that when the program crashes, a crash dump file is created, so that you're not left scratching your head not knowing what to do. From the crash dump file, all you need to do is to load it in as a project and run it. The debugger will stop at where the crash occurred.

Generating a crash dump requires you to do some Win32 coding or you can get one of the several classes that exist that wrap this for you.

If it's UNIX or some variant of it, then Lindey's advice should be followed.

Regards,

Paul McKenzie

[ninja9578]

Unfortunately, I'm using neither *nix or Visual C++. I'm using MinGW and Code::Blocks is my IDE.

[Amleto]

might be a variable that's uninitialised. That kind of thing can cause undefined behaviour

[Paul McKenzie]

Unfortunately, I'm using neither *nix or Visual C++. I'm using MinGW and Code::Blocks is my IDE.

As long as you can make Win32 calls, you can still create a crash dump and use WndDbg to run the crash dump.

Regards,

Paul McKenzie

[davidk]

Use MessageBox() or printf() functions to see the place of code where your program fails. It may take some time to resolve but is useful method when no debuggers or other helpful tools are near.
Use Sleep() to manually slow down the execution of some code.

[Paul McKenzie]

Use MessageBox() or printf() functions to see the place of code where your program fails.

Message boxes are not recommended as a debugging aide, especially for Windows.

The reason why is that displaying of the message box itself can cause bugs or mess up the message pump (if the error is highly dependent on the message pump being active and not interrupted). You certainly should not place message boxes in critical functions such as DllMain() or other such functions.

Instead, the proper way to log messages is to use OutputDebugString( ), and inspect the strings in a program such as DebugView from www.sysinternals.com.

Regards,

Paul McKenzie