SHORE Debugging

The SHORE object storage manager has some heavy weight debugging tools available. These slow code execution quite a bit, but allow tracing on a per file and per function level. There are also many additional w_assert3() available as internal consistency checks.

The original SHORE had only two choices of debugging; the high overhead total package, or nothing at all. This was split up to allow more control of the different debugging and tracing levels.

w_assert1
Shore is always compiled with the level 1 assertions enabled. These catch inconsitencies and abort code execution.
W_DEBUG_NAMES
Many sthread and smlayer objects are synchronization primitives which may have a name associated with them to ease debugging. On some of the objects, the names even change as they are used to represent different resources to make debugging easier!

Normally these objects are not issued names, it is a fairly high overhead operation. Not individually, but across all syncrhonization primitives. These names are enabled with DEBUGCODE is turned on. If you would like them available for a non-debug system, the shore.def option W_DEBUG_NAMES may be defined to name these synchronization objects.

DEBUGCODE
W_DEBUG
w_assert3()

If shore is compiled with the DEBUGCODE option set to ON, the additional consistency checks performed by the w_assert3() checks are performed. This is configured at compile time, and allows for most ordinary problem finding

TRACECODE
W_TRACE

More detailed execution tracing of the code via the DBG and DBGTHRD system can be enabled. This is done with the TRACECODE option set to ON. This is also a compile-time option, and only compiles the debug system in shore. The system must be further enabled at run-time.

DBG
DBGTHRD
The DBG() macro outputs file and line information, as well as the iostream output operators in the args.

DBGTHRD does the same as DBG, but also includes information about which thread is executing.

DEBUG_FLAGS
Setting the environment variable DEBUG_FLAGS enables the run-time tracing/debugging system. The variable is set with space seperated source file names. The names may be of any type of source file where the DBG system macros are used, including header files. For example
	setenv DEBUG_FLAGS "lock_core.cpp tid_t.h"

It is also possible to trace individual functions by name. The function must use the FUNC debug macro to identify itself. Then, upon execution the name of the function can be specified in DEBUG_FLAGS. Use the name of the function specified as an arg to FUNC:

	setenv DEBUG_FLAGS "lock_core_m::acquire"

Regular expressions can be used in DEBUG_FLAGS as another tool.

The different kinds of requests can be mixed and matched in DEBUG_FLAGS.

DEBUG_FILE
The environment variable DEBUG_FILE can be set to the name of an output file which trace info from the DBG system is sent to. If this is not set the debugging output goes to stdout by default.
Stack Red-Zones
STACK_CHECK

Bolo's Home Page
Last Modified: Thu Nov 22 00:52:59 CST 2007
Bolo (Josef Burger) <bolo@cs.wisc.edu>