1. Trace-Based Debugging in Constraint Programming
Ludovic Langevine
SICS
Joint work with Mireille Ducassé (IRISA)
and Pierre Deransart (INRIA)
SweConsNet Workshop
March 7, 2005, Lund

2. Outline Debugging needs in CP(FD) Towards a generic debugging
Observational semantics
Tracers
Dynamic trace analysis

3. CP and Debugging [Meier95,DiSCiPl97]
CP is very declarative but
Numerous variables and constraints (105)
 What is the state of the system?
Data flow embedded in the solver
 What is the behavior of the execution?
Specific debugging tools are needed

4. Observation of Constraint Programs
Four kinds of observation tools exist:
Observation of the search space
Observation of the constraint propagation
Explication of value withdrawal
Application-domain oriented views

5. Observation of the Search Space [Schulte96,Simonis00,Ilog01,Fages02]
Abstract visualization of the behavior of the search (choices, failures, solutions, backtracks)
 search-tree
[Fages02]

6. Observation of the Propagation [Simonis00, Paulin01]
Precise view of some points of the execution:
- each domain reduction
- each constraint awakening
Detailed effects of the constraints
Variables that are hard to value
Relevance of the filtering algorithms

7. Explication of Value Withdrawal [Jussien et al
Explication of Value Withdrawal [Jussien et al. 00, Ågren 02, Lesaint 04]
On each domain reduction, the solver records the cause of the value withdrawal
Linking those causes provides a precise explanation of the inconsistency of a precise value
Dealing with over-constrained problems
Diagnosis of missing solution
Solver implementation has to be designed for computing those explanations

8. Addressed Problem Various complementary tools exist
Each tool needs to collect specific data during the execution
By now, a dedicated instrumentation of the solver is implemented for each tool
High intrusion, repetitive and delicate development
Needs access to solver source code

9. Ad hoc Connections Each connection is hard and costly to develop
Platform 1
Debugging
Tool 1
Platform 2
Debugging
Tool 2
...
...
Platform n
Debugging
Tool m
Each connection is hard and costly to develop

10. Current Situation Few platforms support few tools. No sharing of tools
Debugging
Tool 1
Platform 2
Debugging
Tool 2
...
...
Platform n
Debugging
Tool m
Few platforms support few tools. No sharing of tools

11. Towards a Better Situation
Debugging
Tool 1
Execution
Data
Platform 1
Debugging
Tool 2
...
Debugging
Tool m

12. Execution Data Execution data (trace) Trace schema = definition of
Sequence of events of interest
Reflects the behavior of the execution
Trace schema = definition of
relevant events
attached information

13. Guiding Principle
Debugging tools can be built on top of an execution trace
Debugging
Tool 1
Execution to
observe
Trace
Debugging
Tool 2
Tracer
...
Debugging
Tool m

14. Towards a Generic Trace Schema
Platform 1
Tracer 1
Debugging
Tool 1
Generic
Tracer 2
Platform 2
Debugging
Tool 2
Trace
Schema
...
...
Tracer n
Platform n
Debugging
Tool m

15. Key Issues What is the content of the trace?
Define relevant events and attached data
(trace schema)
Pb.: Tools have versatile needs
 Trace has to be rich
How to produce the trace efficiently?
Pb.: Overhead  Non usability of the tools
A compromise has to be found

16. Rich And Efficient is Possible
Platform 1
Tracer 1
Debugging
Tool 1
Generic
Trace
Requests
Driver
Tracer 2
Platform 2
Debugging
Tool 2
...
...
Debugging
Tool m
Tracer n
Platform n

17. The Results A generic trace schema
Based on an observational semantics
Three formal specializations of the generic semantics (GNU-Prolog, Choco, PaLM)
Four tracers (GNU-Prolog, Choco, PaLM, CHIP)
An architecture to efficiently adapt the trace
The “tracer driver”

18. Generic Trace Schema

19. Observational Semantics
The solver state is formalized by observed state
(The abstract view we have of its state)
Each modification of the observed state is traced as an execution event  state transition rule
Trace = sequence of elementary events sufficient to follow the evolution of the observed state

20. Observed State Model of the state of a FD solver
Set of variables V, domain function D
Set of constraints on V, C
Su: set of domain updates to propagate
Search-tree: set of observed states identified as choice-points.

21. Propagation Awake Sleeping Sc Su Reduce Schedule Post Active Suspend A
Entailed
Reject
Entail
Rejected

22. Example of Transition Rule: reduce
(c,u) A  v  var(c)  Δvc Dv
reduce
Dv  Dv – Δvc, Su  Su  u
“c is the active constraint. An update u has to be propagated. Some values of c are inconsistent for variable v. Values Δvc are removed from Dv, while recording the updates u in Su.”

23. Two Specializations of reduce
(c,u) A  v  var(c)  Δvc  Dv
reduce
(generic)
Dv  Dv – Δvc, Su  Su  u
Ac = {c}  v  var(c)  Δvc  Dv  Δvc    R = 
reduce
(GNU-Prolog)
Dv  Dv – Δvc, Q  Q  u
uu, c, dependence(c,u)
reduce
(PaLM)
A = {(c,u)}  v  var(c)  Δvc,u  Dv  Δvc,u    R = 
DvDv – Δvc,u, QQ  {u’ },     {(v,d,E) | dΔvc,u}
 (E1, …, Ek)  |var(c) such that E = {c}  Ei
i=1 k

24. Benefits of Formalization
The trace has a clear semantics
Limits required understanding of solver’s internals
Helps give meaning to views built on top of the trace
Design of the trace guided by its usability rather than by implementation issues
Set of removed values considered “impossible to trace”

25. Trace Implementations
Codeine for GNU-Prolog
Lazy: trace only what is needed, dynamically parameterized
Can trace the whole observed state at each event
Choco/PaLM: “trace aspect” added at compile-time
The trace can be statically parameterized
Can trace all the modifications of the trace event
(work by Jussien and Rochart)
CHIP

26. GNU-Prolog Trace Example
fd_element(I,[2,5,7],A), (A #= I ; A #= 2).
1 [1] choicePoint node(0)
2 [1] newVariable v1 [ ]
3 [1] newVariable v2 [ ]
4 [1] newConstraint c1 fd_element([v1, [2,5,7], v2])
5 [1] post c1
6 [1] reduce c1 v1 delta=[0, ]
7 [1] reduce c1 v2 delta=[0-1, 3-4, 6, ]
8 [1] suspend c1
9 [2] choicePoint node(1) …

27. Tracer Performance 8 classical programs, from 200k to 400M events
(without the cost of the communication means)
Minimal cost (tracer) : [+3%, +27%] avg.: +9%
 The tracer can be always active
Cost of the search-tree (tree) : [+3%, +27%] avg.: +9%
No extra-cost
Cost of the attributes (default) : [x3, x7,4] avg.: x5
Similar to existing tracers for declarative languages [Somogyi, Appel]

28. Dynamic Trace Analysis

29. A Rich Trace The trace is very rich (1s  2GBytes)
Costly to generate (tracer)
Costly to communicate (IPC)
Costly to process (debugging tool)
A given tool needs only a small subpart of this huge trace
Adapt the trace to the needs of the tool: we propose a tracer driver

30. Tracer driver A module of the tracer which drives the trace generation
The tool describes its needs
event patterns: When and What to trace
The needs can be incrementally updated
Cope with the evolving needs of a tool
Tracer and tool can be synchronized or not
Can investigate some execution states

31. Principles of the Tracer Driver
Solver
Tracer
Driver
Analyzer
Solver
Data
(store,
domains,
...)
Evt. i
Filtering of the evt
Evt. i+1
Evt. i+2
Asynchronous
Evt. Handler
Trace data
Evt. i+3
Evt. i+4
Synchronous
Evt. Handler
Trace data
Evt. i+5
...

32. Event Patterns Class of relevant events Full Trace
predicate
Class of relevant events
Full Trace
selection
function
Selection of trace data
Event Data
Trace of the search-tree
search_tree: when port in [choicePoint, backTo, solution, failure] do current(port, chrono, node)

33. Driver Performance
Its efficiency is inversely proportional to the mean duration of a trace event
OK for CP (a trace event 50ns)
2 orders of magnitude better than the “generate and dump” architecture
We pay only for what we need to trace
The size of the trace is drastically decreased
Search-tree: 1/100

34. The Tracer Driver Is indeed a good compromise Rich trace possible
Only the requested trace is generated

35. Qualitative Assessment
Is the “generic” semantics… generic?
4 tracers implements it (GNU-Prolog, Choco, PaLM, CHIP)
Does the trace schema contain the needed data?
Existing tools have been rebuilt
Innovative tools have been developed
Is the tracer driver powerful?
Several existing architectures can be implemented in this framework (e.g. Opium [Ducassé92], Morphine [Jahier99])
Monitoring, debugging and visualization are enabled in parallel

36. Connectivity Discovery PaLM (EMN) Generic Trace Pavot Schema Choco
(Baudel, Ilog)
PaLM
(EMN)
Generic
Trace
Schema
Pavot
(Arnaud, Inria)
Choco
(EMN)
InfoVis
(Ghoniem, EMN)
Codeine

37. Conclusion A framework to debug programs with constraints
A generic trace schema has been defined
Various tools can be fed with this trace
Development of new debugging tools is easier
A rich trace can be efficient!

38. Trace-Based Debugging in Constraint Programming
Ludovic Langevine
SICS
Joint work with Mireille Ducassé (IRISA)
and Pierre Deransart (INRIA)
SweConsNet Workshop
March 7, 2005, Lund