Ludovic Langevine

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 DebuggingMeier95,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 PropagationSimonis00,
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.
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
10
Current Situation
...
...
Few platforms support few tools. No sharing of
tools
11
Towards a Better Situation
Execution Data
...
12
Execution Data

• Execution data (trace)
• 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

Trace
...
14
Towards a Generic Trace Schema
Generic
Trace Schema
...
...
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
...
...
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
Active
A
Entailed
Rejected
22
Example of Transition Rule reduce
(c,u)? A ? v ? var(c) ? ?vc ?Dv
reduce

• 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)
24
Benefits of Formalization

• The trace has a clear semantics
• Limits required understanding of solvers
  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 0-268435455 3 1 newVariable v2
0-268435455 4 1 newConstraint c1
fd_element(v1, 2,5,7, v2) 5 1 post c1 6
1 reduce c1 v1 delta0, 4-268435455 7 1
reduce c1 v2 delta0-1, 3-4, 6, 8-268435455 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
...
32
Event Patterns

• 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

• 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 (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