1 Ludovic Langevine SICS Joint work with Mireille Ducassé (IRISA) and Pierre Deransart (INRIA) SweConsNet Workshop March 7, 2005, Lund Trace-Based Debugging in Constraint Programming
Feb 13, 2016
1
Ludovic LangevineSICS
Joint work with Mireille Ducassé (IRISA)and Pierre Deransart (INRIA)
SweConsNet Workshop
March 7, 2005, Lund
Trace-Based Debugging in Constraint Programming
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. 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 existEach 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
Platform 2
DebuggingTool 1
Platform n...
DebuggingTool 2
DebuggingTool m
...
Platform 1
Each connection is hard and costly to develop
10
Current Situation
Platform 2
Platform n...
Platform 1
Few platforms support few tools. No sharing of tools
DebuggingTool 1
DebuggingTool 2
DebuggingTool m
...
11
Towards a Better Situation
DebuggingTool 1
Execution
DataDebugging
Tool 2
DebuggingTool m
...
Platform 1
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
Tracer
Guiding Principle
Debugging tools can be built on top of an execution trace
Execution to
observe Trace
DebuggingTool 1
DebuggingTool 2
DebuggingTool m
...
14
Towards a Generic Trace Schema
Tracer 2Platform 2 Trace
Schema
Generic
Tracer nPlatform n...
Platform 1Tracer 1
DebuggingTool 1
DebuggingTool 2
DebuggingTool 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
Tracer 2Platform 2
Tracer nPlatform n
...
Platform 1Tracer 1
GenericTrace
Requests
Driver
Driver
DriverDebugging
Tool 1
DebuggingTool 2
DebuggingTool m
...
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
ActiveA
Entail
ScheduleReduce
Reject
Entailed
Rejected
Post
Suspend
Sleeping
Sc Su
Awake
22
Example of Transition Rule: reduce
“c is the active constraint. An update u has to be propagated. Some values of c are inconsistent for variable v. Values Δv
c are removed from Dv, while recording the updates u in Su.”
(c,u) A v var(c) Δvc Dvreduce
Dv Dv – Δvc, Su Su u
23
Two Specializations of reduce
(c,u) A v var(c) Δvc Dv
Dv Dv – Δvc, Su Su u
reduce(generic)
Ac = {c} v var(c) Δvc Dv Δv
c R = reduce(GNU-Prolog) Dv Dv – Δv
c, Q Q uuu, c, dependence(c,u)
reduce(PaLM)
A = {(c,u)} v var(c) Δvc,u Dv Δv
c,u R =
DvDv – Δvc,u, QQ {u’ }, (v,d,E) | dΔv
c,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 [0-268435455]3 [1] newVariable v2 [0-268435455]4 [1] newConstraint c1 fd_element([v1, [2,5,7], v2])5 [1] post c16 [1] reduce c1 v1 delta=[0, 4-268435455]7 [1] reduce c1 v2 delta=[0-1, 3-4, 6, 8-268435455]8 [1] suspend c19 [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
Data
(store,
domains,
...)
Solver Tracer Driver AnalyzerFiltering of the evt
...
Evt. iEvt. i+1Evt. i+2
Evt. i+3Evt. i+4
Evt. i+5
AsynchronousEvt. Handler
Trace data
Synchronous
Evt. Handler
Trace data
32
Event Patterns
Trace of the search-treesearch_tree: when port in [choicePoint, backTo,
solution, failure] do current(port, chrono, node)
Full Trace predicate Class of relevant events
Event Dataselectionfunction Selection of trace data
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
Qualitative Assessment
36
Connectivity
Codeine
Pavot(Arnaud,
Inria)
InfoVis(Ghoniem,
EMN)
Discovery(Baudel, Ilog)PaLM
(EMN)
Generic
Trace
Schema
Choco
(EMN)
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
Ludovic LangevineSICS
Joint work with Mireille Ducassé (IRISA)and Pierre Deransart (INRIA)
SweConsNet Workshop
March 7, 2005, Lund
Trace-Based Debugging in Constraint Programming