Trace-Based Debugging in Constraint Programming

transcript

Ludovic LangevineSICS

Joint work with Mireille Ducassé (IRISA)and Pierre Deransart (INRIA)

SweConsNet Workshop

March 7, 2005, Lund

Trace-Based Debugging in Constraint Programming

Outline

• Debugging needs in CP(FD)

• Towards a generic debugging

• Observational semantics

• Tracers

• Dynamic trace analysis

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

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

Observation of the Search Space [Schulte96,Simonis00,Ilog01,Fages02]

Abstract visualization of the behavior of the search (choices, failures, solutions, backtracks)

search-tree

[Fages02]

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

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

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

Ad hoc Connections

Platform 2

DebuggingTool 1

Platform n...

DebuggingTool 2

DebuggingTool m

Platform 1

Each connection is hard and costly to develop

Current Situation

Platform 2

Platform n...

Platform 1

Few platforms support few tools. No sharing of tools

DebuggingTool 1

DebuggingTool 2

DebuggingTool m

Towards a Better Situation

DebuggingTool 1

Execution

DataDebugging

Tool 2

DebuggingTool m

Platform 1

Execution Data

• Execution data (trace)– Sequence of events of interest– Reflects the behavior of the execution

• Trace schema = definition of– relevant events– attached information

Tracer

Guiding Principle

Debugging tools can be built on top of an execution trace

Execution to

observe Trace

DebuggingTool 1

DebuggingTool 2

DebuggingTool m

Towards a Generic Trace Schema

Tracer 2Platform 2 Trace

Schema

Generic

Tracer nPlatform n...

Platform 1Tracer 1

DebuggingTool 1

DebuggingTool 2

DebuggingTool m

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

Rich And Efficient is Possible

Tracer 2Platform 2

Tracer nPlatform n

Platform 1Tracer 1

GenericTrace

Requests

Driver

DriverDebugging

Tool 1

DebuggingTool 2

DebuggingTool m

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”

Generic Trace Schema

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

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.

Propagation

ActiveA

Entail

ScheduleReduce

Reject

Entailed

Rejected

Suspend

Sleeping

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

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

(E1, …, Ek) |var(c) such that E = {c} Ei

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”

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

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)…

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]

Dynamic Trace Analysis

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

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

Principles of the Tracer Driver

Solver

(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

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

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

The Tracer Driver

Is indeed a good compromise

• Rich trace possible

• Only the requested trace is generated

• 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

Connectivity

Codeine

Pavot(Arnaud,

Inria)

InfoVis(Ghoniem,

Discovery(Baudel, Ilog)PaLM

Generic

Schema

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!

Ludovic LangevineSICS

Joint work with Mireille Ducassé (IRISA)and Pierre Deransart (INRIA)

SweConsNet Workshop

March 7, 2005, Lund

Trace-Based Debugging in Constraint Programming

Trace-Based Debugging in Constraint Programming

Documents