Debugging

Debugging is the process of finding and resolving bugs (defects or problems that prevent correct operation) within computer programs, software, or systems.

Terms

The act of debugging assumes that the programmer conducting this process:

  1. Knows what correct operation is and knows what incorrect operation is.
  2. Has the ability to observe the programs and/or their output.
  3. Has the ability to change the underlying source code and other program data.
  4. Has the ability to build and test the updated programs.

A non-conformity is a failure to meet one or more requirements.

A defect (bug / error / problem) is incorrect program data (code, input, settings, dependencies, …) that cause a non-conformity

A symptom is observable evidence of a defect

A deterministic defect is a defect that does not change its symptoms under a well-defined set of conditions. Conversely, a non-deterministic defect is a defect that changes its symptoms from run-to-run under a well-defined set of conditions.

A context is the totality of the environment in which a program that exhibits symptoms is running.

A problem report describes one or more symptoms in some context. Each symptom is caused by one ore more defects ( errors / problems ). Evidence of a defect is made observable by one or more symptoms.

An analogous context s one that replicates enough of the original context sufficiently to reproduce a set of symptoms

A lab is a setting in which you have total control over the contexts.

A field is a setting in which you have minimal or no control over the contexts.

Challenges with Debugging

  • Problem reports my be unhelpful, misleading, inadequate, or incorrect in their description of symptoms. The reporter may neglect to add or completely lack knowledge about the product, version, configuration, platform, or some such crucial information.
  • The problem report may not indicate actual problems but rather unexpected or undefined behavior. Unexpected behavior is not always a defect.
  • Collecting program state data may be difficult. Logging information, settings, or crash data could be incomplete, inconclusive, unavailable or completely non-existent.
  • The symptoms may not indicate the cause of the defect and the cause and effects may be distant in space and time.
  • The defects and symptoms may be correlated in that sometimes the symptoms may change as repair progresses.
  • The process of fixing a defect may introduce new defects. This is indicative of quick-fixes and/or messy design.
  • The symptoms may be difficult to reproduce
    • Debugging in the field is not always possible.
    • Constructing an analogous context in a lab is not always feasible or even possible either.
    • Program input is not always available.
    • Symptoms from non-deterministic problems can be especially difficult.

Debuggers

A debugger is a tool meant to facilitate the process of debugging.

The GNU Debugger (GDB)

The following are useful command to know about

  • catch - Set catchpoints to catch events. Can be used to catch system calls and exceptions.
  • set print frame-arguments all | none | presence | scalars - sets the verbosity of prints involving the arguments of the frames (backtrace)
  • set print info-frame auto | location | location-and-address | short-location | source-and-location | source-line - sets the verbosity of info frame calls.
  • ptype /xo - print the type of var and include the ofsets of structure variables in hex. use /o for digital offsets.

Debug Information Daemon (debuginfod)

The debuginfod daemon will serve debug information (symbols) via HTTP. It uses the environmental variable DEBUGINFOD_URLS to set the ip and port on which to serve the information.

$ DEBUGINFOD_URLS=localhost:8002 gdb a.out