Note: This is a work in progress. When it is complete these notes will be removed.
Note: Do not reply to this topic, questions, concerns, comments, etc. are to handled in
Wiki Discussion: Bug hunting toolbox
Note: This is just to get the topic started and hopefully others to jump in and make this useful. Even if you are brand new to Prolog, this is such a basic and fundamental concept that you can and should join in to help improve the value of this Wiki. Join the discussion at Wiki Discussion: Bug hunting toolbox
Note: This post is a wiki page and if you have Trust level: Basic you can edit this by clicking on the pencil icon in the lower right.
These topics also have history so they can be rolled-back if needed.
Note: For now this is just a random collection of items as a list. They still need to be properly formatted and have a more detailed explanation with examples, but for now having them collected in one place is better than not having them at all. As noted, anyone can edit this and even add more details and example code to this.
Individual test can be run from the command line, e.g.
:- begin_tests(test_group). test(01) :- format('done.~w',). :- end_tests(test_group).
This can also be run using gtrace/0, e.g.
?- gtrace. true. [trace] ?- run_tests(test_group:1).
Typically, cross-module calls are considered OK for testing and debugging. You can dynamically import any predicate from a module.
:- export(m:p/1). :- import(m:p/1).
Just for the record, error:has_type/2 should not throw exceptions. That is the task of the more general must_be/2 that uses has_type/2.
- is_of_type(+Type, @Term) is semidet
True if Term satisfies Type.
Runtime determinacy checker (rdet) - can be used to trap predicates that should never fail.
- setup_call_cleanup/3 can also test for determinism.
must_be (+Type, @Term)
True if Term satisfies the type constraints for Type. Defined types are
library(check): Consistency checking - This library provides some consistency checks for the loaded Prolog program.
Cross-referencer - A cross-referencer is a tool that examines the caller-callee relation between predicates, and, using this information to explicate dependency relations between source files, finds calls to non-existing predicates and predicates for which no callers can be found.
- gxref - Run cross-referencer on all currently loaded files and present a graphical overview of the result.
Draw diagrams - Graph drawing software (Wikipedia) or Pen and paper.
GraphViz is a popular console application which has several domain specific languages for describing graphs on which DOT seems to be the most popular. Example here.
Consider Cognitive dimensions of notations
- generate_debug_info(bool, changeable)
true(default) generate code that can be debugged using trace/0, spy/1, etc. Can be set to
falseusing the -nodebug . This flag is scoped within a source file. Many of the libraries have
:- set_prolog_flag(generate_debug_info, false)to hide their details from a normal trace.
See: Append/3 isn’t deterministic if first arg is var?
Add this to your code at the place where you want a conditional break and run
(some_condition -> gtrace ; true),
Using the Logtalk linter to check Prolog modules code: See: Linter
prolog_clause.pl – Get detailed source-information about a clause. This module started life as part of the GUI tracer. As it is generally useful for debugging purposes it has moved to the general Prolog library.
Edit Exceptions in the prolog editor. Who knew that existed and had error defined to trace “if not caught”? - Trace_on_error
?- debug(concurrent). See: Some notes on writing a concurrent programing Howto. Comments and corrections welcome
Related to debugging (trying to understand working code).
When the code is working, there are lots of good test cases and you don’t know what a predicate or line is doing then comment it out, run the test and see what breaks.
Sometimes when using gtrace/0 and single stepping, the code will appear to skip ahead. To see the predicates that were skipped over look in the Call Stack dialog and click on the previous predicate call in the stack. You can continue clicking on the predicate calls in the stack all the way back to the start of the thread.
Note: When using any form of assert with any form of retract, and you are getting unrepeatable results, e.g. unit tests are now failing that use to pass and no change was made to the test or predicates used by the test, then shut down the top level with halt/0 and start again as the Prolog database is probably corrupted.
Advise: If you are not sure how a predicate works before using it, take the time to use it by itself to understand how it works so that you are not compounding your problem by introducing more unknowns. See: Assignment question about lists using findall and between
Interacting with a server
It is often useful to be able to interact with a running Prolog process, notably if it concerns an embedded Prolog engine or server process. This allows for inspecting the database, threads, etc., activate debug/3 statements or reload some code using make/0 without service interrupt. This can be achieved using library(prolog_server), providing a telnet connection to the server. Instead of
telnet, one can also use
nc (net cat). Be aware of the seurity implications! One day, we should provide this functionality on top of libssh and using a pseudo tty such that we can deal with command line editing and ^C.
This idea has one foot in debugging and one foot out so it is included.
Part of debugging is trying to understand which of different strategies may be faster. To make this easier to determine is first_solution/3.
SWI-Prolog is open source so look at the source code if you need.
Most predicates implemented in Prolog can have the source code easily found by
Libraries are in the SWI-Prolog libraries folder
Packages are in other GitHub repositories
Need a duck, try an interactive version. Duckie
Run Goal and write a report on which percentage of the clauses in each file are used by the program and which percentage of the clauses always fail.
Using double negation.
From James Cash’s blog (See blog for details).
In particular, I’ve found it useful when building up a difference list of character codes & wanting to print out what the values are part-way through.
Use color coding in your result messages. See: Adding some color to your text messages
If using the GUI tracer (gtrace), check if the term is cyclic. A cyclic term will show the word
cycle in the value display window.
TODO: Create example code that causes the annotation for the variable name.
If others can’t reproduce the problem run check_installation/0
Also consider/do a full uninstall and then reinstall of the application(s).
Just compile the extension for debugging, run
gdb swipl and load the program. Now break using ^C and set a gdb breakpoint on the function. Continue from gdb, call the predicate from Prolog and gdb should trap the breakpoint.
Once there, Prolog objects are typically either integers or anonymous pointers. There is a large number of utility functions that you can call from gdb to know what these objects are. In this context the most practical is
(gdb) call pl_writeln(a)
a is a variable of type term_t to print the Prolog term. Another useful function is PL_backtrace(depth, flags) to print a Prolog backtrace.
Checking for tail call optimization.
Use prolog_current_frame/1 (ref)
Use gspy/1. (ref)
Using debug/3 with a value that requires calling a predicate to create the value should only occur when debug/3 is active. To achieve this use the format/2 format specification
For an example see: Debugging with difference list of character codes
Nice to know when bug huting.
predicates, modules and functors (name/arity pairs) are not garbage collected. (ref)
Checking for choice points. prolog_choice_attribute/3 and deterministic/1
Use tspy/1 (ref)
load library(http/http_error) (ref)
Use a meta-interpreter (ref)
Use quasiquotations to validate structured text/stream input.
If using an out of cycle release, e.g. head on git, then the web site documentation may be out of sync with the code. To get the updated documentation use help/1 at the command line, e.g.
?- help(redis). (ref)
When using gtrace/0 (ref)
We have the conventional stack and a chain of choice points. Each of these have a stack as well, each eventually links up with the current active environment stack.
We have two types of choice that can be distinguished: those on my parent frame(s) and those that are not. The ones that are not (and thus stand to the right) are subgoals that succeeded with a choice point. If you seek for deterministic last-call optimized code, these are bad.
Note that the source view is an embedded PceEmacs editor in read-only mode. You can used the ‘e’ command to switch to write mode, edit and save using ^x^s, compile using ^c^b (compile buffer).
This allows for fixing things are while running:
- See the output is incorrect (failure, wrong answer, success while failure was expected, etc).
- Use ‘e’, edit, ^x^s, ^c^b, hit ‘r’ to retry and test again.
Another useful command is ^x2, Emacs’
split-window. This is mapped by PceEmacs to create a new editor window showing the same file (initially at the same cursor location). You can use the new window with all usual menu functionality for editing. Multiple editor windows on the same file are kept in sync at any time (they are all visualizations of the same editor buffer ).
This strategy for hot-fixing is something unique to Prolog as retry provides us with a time machine. It takes a little while to get used to, but after that it is a life saver for debugging and fixing issues in a program state that takes long to reproduce. Think of long runtime to reach the critical point or a lot of user interaction for interactive programs.
The main difference is the time machine provided by retry , which backtracks to the start of a goal before re-running it. If the program has no interfering side effects this means you are really back at the old state. This has two enormous advantages. While walking around in languages without such a time machine you have to be very careful not to jump over the buggy function because if you did, you often have to restart from the beginning. When it is no problem to skip over the buggy code, one can use hierarchical debugging: first step over the whole goal. If you do not like the result, retry and step over each of the sub goals until you find one that misbehaves, etc.