DebuggingCrashes

Debugging crashes of a simulation model

For generic help on C++ debugging and using debuggers, check CplusplusDebuggingTips. For help specific to crashes, read on.

Linux

First of all, make sure your simulation program (and preferably OMNeT++ as well) is compiled with DEBUG flags. In configure.user, make sure the CFLAGS line with -g is selected:

 CFLAGS='-g -Wall'
 #CFLAGS='-O2 -DNDEBUG=1'  <-- commented out

If not, change the setting, then ./configure, make clean, make.

In order to debug the crash, you need to launch the simulation under gdb (or some other debugger like kdbg), and run it until the crash.

When the program crashes, you'll get back the gdb prompt, and you can find out where exacly in the program the crash occurred. Type

  bt    

(bt for backtrace), and it will list the function calls the program is in. You can navigate up and down (up, up number) and at each level list the source code (l) and print variables (p variablename).

Windows and Visual C++

Compiling the code for debugging

First, make sure your simulation program is compiled with DEBUG flags. In configuser.vc, make sure you have the following settings (or change them):

 #CFLAGS=$(CFLAGS_RELEASE)
 #LDFLAGS=$(LDFLAGS_RELEASE)
 CFLAGS=$(CFLAGS_DEBUG)
 LDFLAGS=$(LDFLAGS_DEBUG)

Also make sure you're using the debug mode OMNeT++ libraries. In subdirectories inside OMNeT++/lib/ you'll find several copies of the libraries, according to compiler and debug/release settings. Find the approptiate ones and copy them one level up (into lib/). Then recompile your model.

Debugging the crash, using JIT

On Windows, you have just-in-time (JIT) debugging. When the crash dialog ("We are sorry for the inconvenience ... bla bla"), just click the [Debug] button in dialog. This should get you (after clicking a few more buttons) into the Visual Studio IDE's debugger.

If the crash dialog doesn't have a [Debug] button, see Enabling Just-In-Time debugging in MSDN. Apparently, JIT is not available in the Express edition [sigh] -- you have to attach to the process before the crash occurs...

The debugger will likely show disassembly first, choose Go to source from the context menu to see the source code. If that item is not active, then you may have a non-debug compiled program.

Then look at the function call stack. This should be in the lower right panel with the title Call stack. This tells you inside which functions the crash occurred. Select the topmost one that you recognize (ie which is part of some simple module), and the corresponding source code will appear in the main window. Then you can check variables etc.

Common causes of crash

A common source of error is dereferencing a NULL pointer (i.e. a pointer is NULL (0x00000000), and the program is trying to write to (or read from) the location it points). The C++ flavour of this is calling a method of an object whose pointer is NULL. For example, if you have a cMessage* pointer msg which is NULL, then

  msg->setByteLength(15);

or

  ev << "message length: " << msg->length();

will crash. To figure out if this is the case, in different levels of the call stack, check that the referenced pointer variables and the this pointer are not NULL.

Hope this helps; see other debugging topics as well on the Omnetpp? page.

Edit - History - Print - Recent Changes - Search
Page last modified on April 07, 2006, at 11:18 AM