1 / 38

Trace-Based Debugging in Constraint Programming

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. Outline. Debugging needs in CP(FD) Towards a generic debugging Observational semantics Tracers

royal
Download Presentation

Trace-Based Debugging in Constraint Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 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. Platform 1 Debugging Tool 1 Platform 2 Debugging Tool 2 Platform n Debugging Tool m Ad hoc Connections ... ... Each connection is hard and costly to develop

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

  11. Platform 1 Debugging Tool 1 Debugging Tool 2 Debugging Tool m 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. Debugging Tool 1 Debugging Tool 2 Execution to observe Debugging Tool m Tracer Guiding Principle Debugging tools can be built on top of an execution trace Trace ...

  14. Platform 1 Debugging Tool 1 Tracer 1 Platform 2 Debugging Tool 2 Tracer 2 Platform n Debugging Tool m Tracer n 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. Platform 1 Debugging Tool 1 Generic Trace Tracer 1 Driver Platform 2 Debugging Tool 2 Tracer 2 Driver Platform n Requests Debugging Tool m Tracer n Driver 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 sufficientto 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. Awake Sleeping Sc Su Post Reduce Schedule Suspend Entail Reject Propagation Active A Entailed Rejected

  22. DvDv – Δvc, SuSuu 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 Δvc are removed from Dv, while recording the updates u in Su.” (c,u) A  vvar(c) Δvc Dv reduce

  23. 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) A = {(c,u)}vvar(c) Δvc,u DvΔvc,uR =  reduce (PaLM) DvDv – Δvc,u, QQ{u’ },   {(v,d,E) | dΔvc,u} k  (E1, …, Ek)  |var(c)such thatE = {c}Ei i=1 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 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 c1 6 [1] reduce c1 v1 delta=[0, 4-268435455] 7 [1] reduce c1 v2 delta=[0-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 synchronizedor not • Can investigate some execution states

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

  32. predicate Full Trace Class of relevant events selection function Event Data Selection of trace data 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. 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 (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

More Related