Debugging Models
Starting a Model with the Debugger
In this use case, SimWB does not start the model, but instead it is run
via an intermediate "debugprocess" which will start the model running
with the debugger selected in $SIMWB_ROOT/bin/debugprocess. See the
comments at the beginning of that file for configuration details (e.g.,
which debugger should be run, how to add a new debugger, etc.).
This mode is initiated via the Test Sessions tab. From there, select
the Debug Options tab and select which tasks to debug. When starting
the test, be sure to run it via the Run tab and NOT the run button
located at the very top right of the GUI (the debug options will be
ignored if you do).
When you start the test, the selected debugger window is opened and the
model is "paused". This gives you the opportunity to set break points,
examine data, etc., before resuming execution. SimWB will wait forever
in this mode, so don't forget to resume running.
If you are having problems getting the debug window to appear:
- RedHawk 6.0+
By default, DisallowTCP is set to True in
/etc/gdm/gdm.schemas (or /usr/share/gdm/gdm.schemas) which prevents
the program from starting when the debug option is checked in SimWB.
Find the "security/DisallowTCP" key, and modify its default value
to "false" (without the quotes). You will have to log out of X and
log back in for the setting to take effect.
- Pre-RedHawk 6.0
By default, 'DisallowTCP=true' is set in
/etc/gdm/custom.conf which prevents the program from starting when
the debug option is checked in SimWB. The option should be set to
'DisallowTCP=false'. You will have to log out of X and log back in
for the setting to take effect.
You will need to run the command 'xhost +' in a terminal window running
under the X server that is to receive the display to disable access control.
If you are using the NightStar nview debugger, you may need to modify
the NSLM_SERVER line in $SIMWB_ROOT/bin/debugprocess to point nview
to the appropriate license server.
Be aware that when running in this mode, SimWB is not running in a
complete realtime state - the model is running on CPU 0, and overrun
detection is disabled. This may or may not work for you. It depends
entirely on the test configuration, number of tasks, where they are
running, and how sensitive they may be to overruns.
Floating Point Exception (FPE) Handling
A more likely scenario arises when the model generates inappropriate
data (i.e. NaNs, or Not a Number). This can happen when variables
overflow, there is a divide by zero, a zero divided by zero, etc. The
default action taken by the C run-time library is to produce a NaN as
the result and keep processing. This often leads to the propagation of
NaNs throughout the model and eventual failure (a process crash, a hang,
etc.).
SimWB gives you the ability to enable an FPE handler which will cleanly
shut down the test, and optionally start a debugger from the point at
which the exception occurred (thus giving you the ability to determine
the exact cause of the exception).
This is done at model build time by entering the appropriate Compiler
Options in the MLToolkit GUI. There are four options:
- -DFPETRAP
This enables trapping of FPEs, a message detailing which task and
exception occurred, and then test shutdown.
- -DFPEDEBUGGER="DISPLAY=pc1:1 nview --attach=%d"
When defined, everything happens as above, but the task generating
the FPE will be paused while the command defined by FPEDEBUGGER is
built and executed. The command must contain a "%d" which will be
interpreted as the process ID (PID) of the task. So in our example,
the NightView debugger is started and attached to the PID, with
its window appearing on display pc1:1. See the discussion on getting
the debugger window to appear in the previous section.
- -DFPEUNDERFLOW
Most models depend on the C run-time default behavior of replacing
a floating underflow with a zero result. If you need to trap this
behavior, then add this compiler option.
- -g
By default, this option is specified when building a model. It is
required if you intend to run a debugger and expect to see anything
useful. Don't forget to retain this option.
The debugger should be positioned at the point of the exception when
started. If not, you might need to go up the call stack until you get
to the offending code. When you are done, simply kill the task being
debugged and the test should stop (if it hasn't already).