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 shown below.

     ** (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 combinations are:

This is a spypoint. (foo/3 has been spied.)
This is a spypoint; you are returning from a skip.
This is not a spypoint; you are returning from a skip.
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 are:

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, using 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 option.
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 foo without tracing the execution of the predicate write/1. However, if a built-in predicate such as 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: true/0, otherwise/0, false/0, fail/0, =/2, !/0 (cut), ;/2 (or), ,/2 (and), and ->/2 (local cut).