Format of Debugging Messages
After you turn on the debugger and type the goal you want
to debug, the system begins to show the steps of the procedure's
execution. As the system passes through each port of a procedure, it
displays a debugging message on your terminal.
A sample debugging message and an explanation of its symbols are
** (23) 0 Call (dynamic): mymodule:foo(hello,there,_123) ?
- The first two characters indicate whether this is a spypoint and
whether this port is being entered after a
skip. The possible
- This is a spypoint. (
foo/3 has been spied.)
- This is a spypoint; you are returning from a
- This is not a spypoint; you are returning from a
- This is not a spypoint. (For this condition, two blank
spaces are displayed at the left of the message.)
- The number in parentheses is the unique invocation identifier. This
identifies a particular call to the procedure. This number can be used to
correlate the trace messages for the various ports, since it is unique for
every invocation. It will also give an indication of the number of
procedure calls made since the start of the execution. The invocation
counter is reset to 1 whenever a new goal is typed at the top level, and is
also reset when retries (see dbg-bas-tra-ccf) are performed.
- The next number is the current depth -- that is, the number
of direct ancestors this goal has. The ancestors can be printed using
the g debugging option. The depth increases as procedures are
called and decreases as procedures return. There may be many goals at
the same depth, which is why the unique invocation identifier is also
provided. If the depth is shown as 0, this spypoint is on a compiled
procedure and no depth or ancestor information is available. The depth
is reset to 0 when a compiled procedure is executed, and begins growing
again from there afterward.
- The next word shows the particular port: Head, Call, Exit,
Done, Redo, Fail, or Exception.
- The next parenthesized item, if present, indicates
when there is something unusual about the predicate. The possibilities
- for built-in predicates; or
- for locked predicates; or
- for undefined predicates; or
- for foreign predicates (defined in another programming language); or
- for dynamic predicates; or
- for multifile predicates.
- If the procedure currently being debugged was loaded into a
module other than
user, the module name will be displayed here, followed
by a colon.
- The goal is then printed so that its current
instantiation state can be seen. (At Redo ports, the instantiation state
shown is the same as at the previous Exit.)
This is done using
print/1 so that all
goals displayed by the debugger can be "pretty printed", if the user wishes,
portray/1 clauses. The debugger also maintains a print depth limit
and will only show terms nested down to this depth. The system initially
uses a limit of 10, but this can be changed using the < debugging
- The final
? is the prompt indicating that you should type in one of
the option codes (see next section). If this particular port is unleashed,
there will be no prompt and the debugger will continue to the next port.
Please note: Since the system does not allow the placing of spypoints on built-in
predicates, the only way to show the execution of built-in predicates typed
at the main Prolog prompt is to select trace mode. For example, if
you typed write(foo). at the main Prolog prompt with the debugger
in debug mode, the system would simply display the word
tracing the execution of the predicate
However, if a built-in predicate
write/1 were called from within a program, the execution of the
predicate would be shown in any case that the execution of the procedure
containing it would be shown. There are a few basic built-in predicates for
which information is not displayed because it is more convenient not to
trace them. These are:
,/2 (and), and
->/2 (local cut).