Debugging Overhaul

Like many projects of its size, VisIt has grown a log-based debugging system. See UserDebug and Debug logs for more information.

The current log implementation leaves some features to be desired. Here we discuss some of the problems with the current system and the goals of a potential new system. Then we'll discuss some possible solutions, including solutions other projects have developed.

Existing Implementation

The debug logs are defined in the VisIt header file DebugStream.h. Five std::ostream's are declared, with #defines to create the client-visible debug macros. The streams are numbered sequentially starting at one; higher numbers imply more debugging information. Enabling level N logs will cause all the debug messages at level N to be output, as well as all level N-1 debug messages -- recursively.

Problems

Debug logs are incredibly verbose. For this reason, they are useful in identifying the source of a problem when you are not sure of its location, but difficult to manage when you have narrowed down the problem somewhat. As an example, say a developer notices a few messages at level 4 which change in the presence of a bug they are chasing. While debugging further, they must leave at least debug level 4 on at all times. Every test run iteration, a developer must wade through the copious amount of output to find the few relevant debug messages.

Current debug messages are difficult to identify. They lack any kind of tag which can give a clue as to where the message comes from. This forces the developer to utilize an annoying and error-prone grep through the source tree to find the message's source.

Logs have a loose affiliation with debugging: exceptions appear in the debug1 logs. However there is little support for a developer to base error checking on a user's load-time specification of debugging. We would like a standardized, unified mechanism for a user to enable 'expensive' error checking as a complement to debug logs.