Controlling search space materialization in a practical declarative debugger

Authors:
Ian MacLarty;Zoltan Somogyi
Affiliations:
Department of Computer Science and Software Engineering, University of Melbourne, Australia;Department of Computer Science and Software Engineering, University of Melbourne, Australia
Venue:
PADL'06 Proceedings of the 8th international conference on Practical Aspects of Declarative Languages
Year:
2006

Citing 5
Cited 1

Tracing piece by piece: affordable debugging for lazy functional languages

Proceedings of the fourth ACM SIGPLAN international conference on Functional programming
Algorithmic Program DeBugging

Algorithmic Program DeBugging
The Evaluation Dependence Tree as a Basis for Lazy FunctionalDebugging

Automated Software Engineering
Rational Debugging in Logic Programming

Proceedings of the Third International Conference on Logic Programming
Divide-and-query and subterm dependency tracking in the mercury declarative debugger

Proceedings of the sixth international symposium on Automated analysis-driven debugging

Design and implementation of a tracer driver: Easy and efficient dynamic analyses of constraint logic programs1

Theory and Practice of Logic Programming

Quantified Score

Hi-index	0.00

Visualization

Abstract

While the idea of declarative debugging has been around for a quarter of a century, the technology still hasn’t been adopted by working programmers, even by those working in declarative languages. The reason is that making declarative debuggers practical requires solutions to a whole host of problems. In this paper we address one of these problems, which is that retaining a complete record of every step of the execution of a program is infeasible unless the program’s runtime is very short, yet this record forms the space searched by the declarative debugger. Most parts of this search space therefore have to be stored in an implicit form. Each time the search algorithm visits a previously unexplored region of the search space, it must decide how big a part of the search space to rematerialize (which it does by reexecuting a call in the program). If it materializes too much, the machine may start to thrash or even run out of memory and swap space. If it materializes too little, then materializing all the parts of the search space required by a debugging session will require too many reexecutions of (parts of) the program, which will take too long. We present a simple algorithm, the ideal depth strategy, for steering the ideal middle course: minimizing reexecutions while limiting memory consumption to what is feasible. We show that this algorithm performs well even when used on quite long running programs.