Topic: animation
Topic: debugging by usage rules
Topic: debugging techniques
Topic: error messages
Topic: execution profile
Topic: histogram
Topic: incremental execution
Topic: logging data and events
Topic: monitored variable
Topic: path expression
Topic: testing user interfaces by transcripts
| |
Summary
Program tracing is an effective debugging tool for analyzing program behavior when bugs are detected. The user has information detailing the program's execution path through each data structure, recursive structure, and procedure. The trace is generated by print statements added to the program or by selective program control. Automatic traces may follow procedure calls, modification to selected variables, initial execution of each statement, or profile execution frequency. At any time, memory can be dumped with labeled variables and structures. Tracing usually produces large amounts of printed information of which little will be used. An alternative is visual display of monitored variables. For instance hardware patch boards may include LEDs or probe locations for indicating the board's internal state. (cbb 5/80)
An ideal program could be understood statically, without a trace. For this reason, Jackson argues that hierarchical structures are better than reused ones. (cbb 1/92)
Subtopic: observability
Quote: modern, software systems can not be observed without modifying the software itself [»cantB2_2006]
| Quote: DTrace provides safe and heterogenous dynamic instrumentation of production systems; arbitrary actions, predicates, and in situ aggregation [»cantB2_2006]
| Quote: DTrace providers create probes via the DTrace framework; allows tracing at any level of the system, even across protection boundaries
| Quote: DTrace providers declare translators that translate from implementation-specific data structures into abstract ones; e.g., an io provider has 'start' and 'done' instead of 'fstat', etc. [»cantB2_2006]
| Subtopic: development vs. production environments
Quote: conditional trace and asserts bifurcates software; performance problems are found in production, but can only be understood in a development environment [»cantB2_2006]
| Subtopic: trace execution
Quote: debug real time software by always collecting an activity log; called non repeated runs approach [»tsurS_1982]
| Quote: use a replay log to distinguish benign data races from harmful ones; demonstrate the harmful data race; identify races with happens-before [»naraS6_2007]
| Subtopic: adaptive profile
Quote: adaptive profiling based on instrumented and non-instrumented procedures; use counters to turn on and off full program tracing [»chilTM10_2004]
| Quote: implemented adaptive profiler (SWAT) with the Vulcan binary rewriting system
| Subtopic: object dereference
Quote: execution trace as object dereference; field load/store, array load/store w/o index, method call/return, object create, and end program [»martM10_2005]
| Subtopic: on-line pattern match
Quote: a PQL query is a pattern to be matched on the execution trace; typed variables match an object of that type; subqueries; action to perform on match [»martM10_2005]
| Quote: runtime overhead of PQL ranges from 9% to 125%; static analysis helps a lot; max is 19x slowdown [»martM10_2005]
| Subtopic: calling context
Quote: the probabilistic calling context (PCC) is a hash of the calling context and call site; 3% overhead for Java; e.g., detecting anomalous behavior after a training session [»bondMD10_2007]
| Quote: if a program reuses components then the context of a statement depends on the prior execution history; requires a trace to debug [»jackMA_1975]
| Subtopic: tracked value
Quote: track the origin of nulls by piggybacking an id; may help with diagnosis in one third of cases [»bondMD10_2007a]
| Subtopic: visualizing execution
Quote: Cornell_Program_Synthesizer can trace execution on a split screen of program text and program output [»teitT6_1981]
| Quote: a comment template in Cornell_Program_Synthesizer acts as a single instruction for flow-tracing and pacing [»teitT9_1981]
| Quote: if display program trace at full speed, brightly lit lines are heavily executed [»teitT6_1981]
| Subtopic: monitor program
Quote: monitoring is extracting dynamic information about a process during execution [»snodR5_1984]
| Quote: report monitored information as event relations (where:new state:time) and interval relations (condition:start time:end time) [»snodR5_1984]
| Quote: present the dynamic behavior of a monitored program by a collection of temporal relations [»snodR5_1984]
| Quote: implant sensors to monitor a program, either traced periodically or sampled on demand [»snodR5_1984]
| Quote: use TQuel for specifying monitored information by specifying the content of derived relations
| Quote: compile TQuel queries for the incremental update of temporal relations from a monitored program [»snodR5_1984]
| Quote: use hoot instructions to listen to a routine's progress; repeated pulses generates a steady note, rich in harmonies; a single pulse is audible [»turiA3_1951]
| Subtopic: invocation tree
Quote: explore invocation tree on error by reporting operation name and error within context of operation [»efeK11_1987]
| Quote: explore invocation tree with why? to move down tree and then? to show next action [»efeK11_1987]
| Subtopic: trace options
Quote: traces statement 2 or more times; arguments, results, source, execution count; unexecuted instructions, procedure calls [»sattEH5_1975, OK]
| QuoteRef: sattEH5_1975 ;;13 dump of arrays shows first, last and up to six middle values
| Quote: check a program by interpreting the program instead of executing it directly; print additional information [»wilkMV_1951]
| Subtopic: selective tracing
QuoteRef: sattEH5_1975 ;;4 bounded amount of possible diagnostic output
| Quote: selective tracing works best for simple sequencing, explicit assignments, subtle bugs; poor for nested functions [»sattEH5_1975, OK]
| QuoteRef: sattEH5_1975 ;;252 large programs cause difficulty for tracing cause information is buried in irrelevant data
| QuoteRef: sattEH5_1975 ;;32 Hartley and Wheeler: Autotrace- traces by output whenever more statements executed between labels then before
| Subtopic: trace every routine
Quote: every subroutine should have write statements that report values at the start and/or end; detect most bugs by tracing [»einbJM1_1988]
| Quote: since the message handler sees all messages, messages are easily traced for simulation and checking [»katzL_1981]
| Quote: trace program execution by printing a letter when each subroutine executes [»wilkMV_1951]
| Quote: the check routine prints a letter for each order and a new line line for each control transfer. This compact trace made it easy to follow the program [»campM1_1980]
| Subtopic: maximal repeating patterns
Quote: locating user interface problems by maximal repeating patterns also provides the raw transcript; helpful for debugging [»siocAC10_1991]
| Subtopic: tracing vs. dumps
Quote: Wilkes preferred print orders and post-mortem routines over "peeping", i.e., observing a program's progress through a CRT monitor [»wilkMV_1951]
| Subtopic: generate specification from trace -- trace is feasible, text infeasible
Quote: specification mining analyzes a program's trace of API or ADT calls; produces state machines with temporal and data dependencies [»ammoG1_2002]
| Quote: a call trace of an API or ADT consists of feasible and error-free paths; while a program's text contains infeasible and buggy paths
|
Related Topics
Topic: animation (20 items)
Topic: debugging by usage rules (41 items)
Topic: debugging techniques (23 items)
Topic: error messages (37 items)
Topic: execution profile (43 items)
Topic: histogram (5 items)
Topic: incremental execution (22 items)
Topic: logging data and events (17 items)
Topic: monitored variable (28 items)
Topic: path expression (14 items)
Topic: testing user interfaces by transcripts (13 items)
|