Designing a source-level debugger for cognitive agent programs

When an agent program exhibits unexpected behaviour, a developer needs to locate the fault by debugging the agent’s source code. The process of fault localisation requires an understanding of how code relates to the observed agent behaviour. The main aim of this paper is to design a source-level debugger that supports single-step execution of a cognitive agent program. Cognitive agents execute a decision cycle in which they process events and derive a choice of action from their beliefs and goals. Current state-of-the-art debuggers for agent programs provide insight in how agent behaviour originates from this cycle but less so in how it relates to the program code. As relating source code to generated behaviour is an important part of the debugging task, arguably, a developer also needs to be able to suspend an agent program on code locations. We propose a design approach for single-step execution of agent programs that supports both code-based as well as cycle-based suspension of an agent program. This approach results in a concrete stepping diagram ready for implementation and is illustrated by a diagram for both the Goal and Jason agent programming languages, and a corresponding full implementation of a source-level debugger for Goal in the Eclipse development environment. The evaluation that was performed based on this implementation shows that agent programmers prefer a source-level debugger over a purely cycle-based debugger.     

Debugging mixed‐environment programs with Blink

Programmers build large‐scale systems with multiple languages to leverage legacy code and languages best suited to their problems. For instance, the same program may use Java for ease of programming and C to interface with the operating system. These programs pose significant debugging challenges, because programmers need to understand and control code across languages, which often execute in different environments. Unfortunately, traditional multilingual debuggers require a single execution environment. This paper presents a novel composition approach to building portable mixed‐environment debuggers, in which an intermediate agent interposes on language transitions, controlling and reusing single‐environment debuggers. We implement debugger composition in Blink, a debugger for Java, C, and the Jeannie programming language. We show that Blink is (i) simple: it requires modest amounts of new code; (ii) portable: it supports multiple Java virtual machines, C compilers, operating systems, and component debuggers; and (iii) powerful: composition eases debugging, while supporting new mixed‐language expression evaluation and Java native interface bug diagnostics. To demonstrate the generality of interposition, we build prototypes and demonstrate debugger language transitions with C for five of six other languages (Caml, Common Lisp, C#, Perl 5, Python, and Ruby) without modifications to their debuggers. Using real‐world case studies, we show that diagnosing language interface errors require prior single‐environment debuggers to restart execution multiple times, whereas Blink directly diagnoses them with one execution. Copyright © 2014 John Wiley & Sons, Ltd.     

Empirical studies on programming language stimuli

Comprehending and debugging computer programs are inherently difficult tasks. The current approach to building program execution and debugging environments is to use exclusively visual stimuli on programming languages whose syntax and semantics has often been designed without empirical guidance. We present an alternative: Sodbeans, an open-source integrated development environment designed to output carefully chosen spoken auditory cues to supplement empirically evaluated visual stimuli. Originally designed for the blind, earlier work suggested that Sodbeans may benefit sighted programmers as well. We evaluate Sodbeans in two experiments. First, we report on a formal debugging experiment comparing (1) a visual debugger, (2) an auditory debugger, and (3) a multimedia debugger, which includes both visual and auditory stimuli. The results from this study indicate that while auditory debuggers on their own are significantly less effective for sighted users when compared with visual and multimedia debuggers, multimedia debuggers might benefit sighted programmers under certain circumstances. Specifically, we found that while multimedia debuggers do not provide instant usability, once programmers have some practice, their performance in answering comprehension questions improves. Second, we created and evaluated a pilot survey analyzing individual elements in a custom programming language (called HOP) to garner empirical metrics on their comprehensibility. Results showed that some of the most widely used syntax and semantics choices in commercial programming languages are extraordinarily unintuitive for novices. For example, at an aggregate level, the word for , as in a for loop, was rated reliably worse than repeat by more than 673% by novices. After completing our studies, we implemented the HOP programming language and integrated it into Sodbeans.     

Efficient and scalable omniscient debugging for model transformations

This paper discusses a technique for supporting omniscient debugging for model transformations, which are used to define core operations on software and system models. Similar to software systems developed using general-purpose languages, model transformations are also subject to human error and may possess defects. Existing model-driven engineering tools provide stepwise execution to aid developers in locating and removing defects. In this paper, we describe our investigation into a technique and associated algorithms that support omniscient debugging features for model transformations. Omniscient debugging enables enhanced navigation and exploration features during a debugging session beyond those possible in a strictly stepwise execution environment. Finally, the execution time performance is comparatively evaluated against stepwise execution, and the scalability (in terms of memory usage) is empirically investigated.     

Dynamic Query-Based Debugging of Object-Oriented Programs

Program errors are hard to find because of the cause-effect gap between the instant when an error occurs and when the error becomes apparent to the programmer. Although debugging techniques such as conditional and data breakpoints help in finding errors in simple cases, they fail to effectively bridge the cause-effect gap in many situations. This paper proposes two debuggers that provide programmers with an instant error alert by continuously checking inter-object relationships while the debugged program is running. We call such tool a dynamic query-based debugger. To speed up dynamic query evaluation, our debugger implemented in portable Java uses a combination of program instrumentation, load-time code generation, query optimization, and incremental reevaluation. Experiments and a query cost model show that selection queries are efficient in most cases, while more costly join queries are practical when query evaluations are infrequent or query domains are small. To enable query-based debugging in the middle of program execution in a portable way, our debugger performs efficient Java class file instrumentation. We call such debugger an on-the-fly debugger. Though the on-the-fly debugger has a higher overhead than a dynamic query-based debugger, it offers additional interactive power and flexibility while maintaining complete portability.     

An approach to the development of debuggers that use semantics of constructs of parallel programs

In the paper, a new approach to the development of interactive debuggers for parallel programs that use message-passing model is suggested. The basic idea of the approach is to design a debugger specific to a particular language or a parallel programming library and to use information about the semantics of constructs used in the parallel program for processing commands of the step-by-step execution and data representation. The development of the user interface and internal debugger structure, as well as their implementations in the debuggers for mpC programs and programs using the MPI library, are considered.Translated from Programmirovanie, Vol. 31, No. 1, 2005. Original Russian Text Copyright © 2005 by Kalinov, Karganov, Khorenko.     

The Implementation Technology of the Mercury Debugger

Every programming language needs a debugger. Mercury now has three debuggers: a simple procedural debugger similar to the tracing systems of Prolog implementations, a prototype declarative debugger, and a debugger based on the idea of automatic trace analysis. In this paper, we present the shared infrastructure that underlies the three debuggers, and describe the implementation of the procedural debugger. We give our reasons for each of our main design decisions, and show how several of these decisions are rooted in our experience with the debugging of large programs working with large data structures.     

Extension Language Automation of Embedded System Debugging

Embedded systems contain several layers of target processing abstraction. These layers include electronic circuit, binary machine code, mnemonic assembly code, and high-level procedural and object-oriented abstractions. Physical and temporal constraints and artifacts within physically embedded systems make it impossible for software engineers to operate at a single layer of processor abstraction. The Luxdbg embedded system debugger exposes these layers to debugger users, and it adds an additional layer, the extension language layer, that allows users to extend both the debugger and its target processor capabilities. Tcl is Luxdbg's extension language. Luxdbg users can apply Tcl to automate interactive debugging steps, to redirect and to interconnect target processor input-output facilities, to schedule multiple processor execution, to log and to react to target processing exceptions, to automate target system testing, and to prototype new debugging features. Inclusion of an extension language like Tcl in a debugger promises additional advantages for distributed debugging, where debuggers can pass extension language expressions across computer networks.     

Sequential debugging at a high level of abstraction

Efforts to build a better mousetrap for bugs in sequential programs are described. The resulting debugger, called Dalek, is intended to remedy limitations in conventional execution harnesses. Beyond the simple `stop and look' features offered by typical breakpoint debuggers, Dalek offers a rich control and query language. Dalek's linguistic capabilities for treating sequences of program events offer an improvement over scratch paper as a compensatory technology for human memory limitations. Example applications are given. The very interactive, dynamic style of debugging encouraged by Dalek is discussed     

Dynamic Reverse Code Generation for Backward Execution

The need for backward execution in debuggers has been raised a number of times. Backward execution helps a user naturally think backwards and, in turn, easily locate the cause of a bug. Backward execution has been implemented mostly by state-saving or checkpointing, which are inherently not scalable. In this paper, we present a method to generate reverse code, so that backtracking can be performed by executing reverse code. The novelty of our work is that we generate reverse code on-the-fly, while running a debugger, which makes it possible to apply the method even to debugging multi-threaded programs.     

Retargetability and Extensibility in a Parallel Debugger

This paper describes the design and implementation ofPanorama, a parallel debugger for MIMD message-passing computers. Programmers can readily adapt Panorama to new parallel platforms and extended it to include their ownviewsof a target program. The system comes with three built-in graphical program views, and it also includes a software tool to help programmers design and implement new views. Panorama avoids detailed dependence on target architectures by using thebase debuggersupplied by each hardware vendor to carry out low-level debugging tasks such as setting breakpoints and examining data. Since the interfaces and capabilities of base debuggers vary, we have developed a strategy that models interactions between Panorama and base debuggers. The model separates general-purpose code from the special-case functions that handle specific debugger characteristics. The resulting system is easy to adapt and free from the clutter of conditionally-executed, special-case code.     

A system for debugging via online tracing and dynamic slicing

Dynamic slicing is a promising trace based technique that helps programmers in the process of debugging. In order to debug a failed run, dynamic slicing requires the dynamic dependence graph (DDG) information for that particular run. The two major challenges involved in utilizing dynamic slicing as a debugging technique are the efficient computation of the DDG and the efficient computation of the dynamic slice, given the DDG. In this paper, we present an efficient debugger, which first computes the DDG efficiently while the program is executing; dynamic slicing is later performed efficiently on the computed DDG, on demand. To minimize program slowdown during the online computation of DDG, we make the design decision of not outputting the computed dependencies to a file, instead, storing them in memory in a specially allocated fixed size circular buffer. The size of the buffer limits the length of the execution history that can be stored. To maximize the execution history that can be maintained, we introduce optimizations to eliminate the storage of most of the generated dependencies, at the same time ensuring that those that are stored are sufficient to capture the bug. Experiments conducted on CPU‐intensive programs show that our optimizations are able to reduce the trace rate from 16 to 0.8 bytes per executed instruction. This enables us to store the dependence trace history for a window of 20 million executed instructions in a 16‐MB buffer. Our debugger is also very efficient, yielding slicing times of around a second, and only slowing down the execution of the program by a factor of 19 during the online tracing step. Using recently proposed architectural support for monitoring, we are also able to handle multithreaded programs running on multicore processors. Copyright © 2011 John Wiley & Sons, Ltd.     

Experience with a portable debugging tool

Debugging tools are usually highly machine and compiler dependent programs that are either impossible to move or require a tremendous effort to move to another machine. This paper describes Ctrace, a portable debugging tool for the C language that provides the same, easy-to-use debugging environment on all machines. A similar debugger can be written for any language. Ctrace is a preprocessor that inserts source language debugging code into the program before compilation that, at execution time, prints the text of each source language statement along with the values of variables it uses and modifies. Redundant trace output from program loops is detected and eliminated. Tracing can be limited to selected statements or functions. Ctrace has shown its usefulness and popularity by its installation on over 200, computers at Bell Laboratories. It has proven its portability by being used to test software on four different operating systems and nine different processors.     

Replay-based debugging of occam programs

Parallel programs are intrinsically non-deterministic, and therefore the techniques of cyclical debugging that are commonly used for sequential programs are not suitable for parallel ones. This paper proposes a method to reproduce Occam program behaviour. Saving information on the timer values input by the program and the guards selected at run-time on alternative commands allows program replay, i.e. it makes it possible to re-execute the program deterministically with the same inputs following the same instruction path. This enables the software developer to use tools such as debuggers and intrusive monitors to help identify program faults. After discussing possible implementations of the proposed technique, IRD (an interactive replay debugger for Occam programs) is described. Finally, the use of the IRD in a sample debug session is presented as an example.     

The value of slicing while debugging

The paper describes a study that explored the relationship of program slicing to (1) code understanding gained while debugging, and to (2) a debugger's ability to localize the program fault area. The study included two experiments. The first experiment compared the program understanding abilities of two classes of debuggers: those who slice while debugging and those who do not. For debugging purposes, a slice can be thought of as a minimal subprogram of the original code that contains the program faults. Those who only examine statements within a slice for correctness are considered slicers; all others are considered non-slicers. Using accuracy of subprogram construction as a measure of understanding, it was determined that slicers have a better understanding of the code after debugging. The second experiment compared debugger fault localization abilities before and after a training session on how to use slicing in debugging. Using time as a measure of ability, it was shown that slicing while debugging improves a debugger's ability to localize the program fault area.     

Detecting nondeterminacy in parallel programs

Methods and tools for detecting nondeterminacy in programs for shared-memory multiprocessors are discussed. The approach described divides the debugging chore into two phases. The first phase uses tools that automatically detect nondeterminacy to debug synchronization errors, assuming it is decided at the outset to make the parallel program determinate. At the end of this phase, it is known that the program is determinate, that timing differences will not affect results, and the debugging sessions are repeatable. In the second phase, an interactive break-point debugger is used to find arithmetic and logical errors. The proposed tools fall into two groups: those that statically analyze the source program and those that analyze an execution trace of the program     

Design of an interactive debugger for FORTRAN: MANTIS

MANTIS is a natural debugging facility for the FORTRAN language subsystem on the PDP-10. It was designed and implemented in an existing language subsystem in order to facilitate program preparation and debugging in the time sharing environment available on the PDP-10. Suitable debugging facilities should be included in the initial design of language subsystems. Language subsystems to run in time sharing operating systems should offer debugging facilities that exploit the interactive environment available to the user. This paper describes experience gained in designing and adding a useful interactive debugger to an existing FORTRAN subsystem. Objectives, implementation experience and system features are discussed and are related to the general problem of designing debuggers for language subsystems.     

Grammar‐driven generation of domain‐specific language debuggers

Domain‐specific languages (DSLs) assist a software developer (or end‐user) in writing a program using idioms that are similar to the abstractions found in a specific problem domain. Tool support for DSLs is lacking when compared with the capabilities provided for standard general‐purpose languages (GPLs), such as Java and C++. For example, support for debugging a program written in a DSL is often non‐existent. The lack of a debugger at the proper abstraction level limits an end‐user's ability to discover and locate faults in a DSL program. This paper describes a grammar‐driven technique to build a debugging tool generation framework from existing DSL grammars. The DSL grammars are used to generate the hooks needed to interface with a supporting infrastructure constructed for an integrated development environment that assists in debugging a program written in a DSL. The contribution represents a coordinated approach to bring essential software tools (e.g. debuggers) to different types of DSLs (e.g. imperative, declarative, and hybrid). This approach hides from the end‐users the accidental complexities associated with expanding the focus of a language environment to include debuggers. The research described in this paper addresses a long‐term goal of empowering end‐users with development tools for particular DSL problem domains at the proper level of abstraction without depending on a specific GPL. Copyright © 2007 John Wiley & Sons, Ltd.     

Debuggers and logging frameworks

The testing, diagnostic, and repair equipment of many professions is horrendously expensive. Assuming that the bug-finding systems the author discussed that program code a clean bill of health, our next alternatives for productively pinpointing errors that have crept into our code are debuggers or logging instrumentation. Our toolbag is full of useful debugging tools. Being an expert user of a debugger and a logging framework is a sign of professional maturity.     

A visual debugger for pure Prolog

This work involves the design and coding of an interpreter for pure Prolog and building a visual debugger for it. Most of the available Prolog interpreters contain some tracing facilities. They do not incorporate, however, a comprehensive visual debugger. The interpreter performs the operations of parsing, unification, resolution, and search in a state-space representation of the Prolog program. The visual debugger incorporates the graphical visualization and the manipulation of the SLD resolution tree. The user visualizes the execution of a pure Prolog program and interacts with the program inside a windowing environment. The program execution may be viewed without interruption or the execution can be stopped at any moment in time. At this point the “snapshot” can be scrutinized with the help of break-points and data displays. This software aims itself to those who wish to observe the actual process of predicate unification, substitution, resolution and goal matching in a Prolog program and to visually interact with the interpreter using a highly friendly and pleasing user interface. An advanced feature, referred to as debugging on the tree, provides the user with the ability to insert break-points directly on the SLD tree, to choose the path of execution, and change the search mode. The resultant search algorithm can be a mixture of depth-first and breadth-first search, avoiding infinite search paths.