18.5 Debugging

Racket’s built-in debugging support is limited to context (i.e., “stack trace”) information that is printed with an exception. In some cases, for 3m and CGC variants of Racket, disabling the JIT compiler can affect context information. For the CS variant of Racket, setting the PLT_CS_DEBUG environment variable causes compilation to record expression-level context information, instead of just function-level information.

The errortrace library supports more consistent (independent of the compiler) and precise context information. The racket/trace library provides simple tracing support. Finally, the DrRacket programming environment provides much more debugging support.

18.5.1 Tracing

The racket/trace library mimics the tracing facility available in Chez Scheme.

When traced procedures invoke each other, nested invocations are shown by printing a nesting prefix. If the nesting depth grows to ten and beyond, a number is printed to show the actual nesting depth.

The trace form can be used on an identifier that is already traced. In this case, assuming that the variable’s value has not been changed, trace has no effect. If the variable has been changed to a different procedure, then a new trace is installed.

Tracing respects tail calls to preserve loops, but its effect may be visible through continuation marks. When a call to a traced procedure occurs in tail position with respect to a previous traced call, then the tailness of the call is preserved (and the result of the call is not printed for the tail call, because the same result will be printed for an enclosing call). Otherwise, however, the body of a traced procedure is not evaluated in tail position with respect to a call to the procedure.

The result of a trace expression is #<void>.

trace can also be used to debug syntax transformers. This is verbose to do directly with trace; refer to trace-define-syntax for a simpler way to do this.

When tracing syntax transformers, it may be helpful to modify current-trace-print-args and current-trace-print-results to make the trace output more readable; see current-trace-print-args for an extended example.

For example:

By default, trace prints out syntax objects when tracing a syntax transformer. This can result in too much output if you do not need to see, e.g., source information. To get more readable output by printing syntax objects as datums, we can modify the current-trace-print-args and current-trace-print-results. See current-trace-print-args for an example.

The result of an untrace expression is #<void>.

Modifying this and current-trace-print-results is useful to to get more readable or additional output when tracing syntax transformers. For example, we can use debug-scopes to add scopes information to the trace, (see debug-scopes for an example), or remove source location information to just display the shape of the syntax object

In this example, we update the printers current-trace-print-args and current-trace-print-results by storing the current printers (ctpa and ctpr) to cast syntax objects to datum using syntax->datum and then pass the transformed arguments and results to the previous printer. When tracing, syntax arguments will be displayed without source location information, shortening the output.

We must take care when modifying these parameters, especially when the transformation makes assumptions about or changes the type of the argument/result of the traced identifier. This modification of current-trace-print-args and current-trace-print-results is an imperative update, and will affect all traced identifiers. This example assumes all arguments and results to all traced functions will be syntax objects, which is the case only if you are only tracing syntax transformers. If used as-is, the above code could result in type errors when tracing both functions and syntax transformers. It would be better to use syntax->datum only when the argument or result is actually a syntax object, for example, by defining maybe-syntax->datum as follows.

It defaults to ">".

It defaults to "<".