A dataflow approach to event-based debugging

This paper describes a novel approach to event-based debugging. The approach is based on a (coarsegrained) dataflow view of events: a high-level event is recognized when an appropriate combination of lower-level events on which it depends has occurred. Event recognition is controlled using familiar programming language constructs. This approach is more flexible and powerful than current ones. It allows arbitrary debugger language commands to be executed when attempting to form higher-level events. It also allows users to specify event recognition in much the same way that they write programs. This paper also describes a prototype, Dalek, that employs the dataflow approach for debugging sequential programs. Dalek demonstrates the feasibility and attractiveness of the dataflow approach. One important motivation for this work is that current sequential debugging tools are inadequate. Dalek contributes toward remedying such inadequacies by providing events and a powerful debugging language. Generalizing the dataflow approach so that it can aid in the debugging of concurrent programs is under investigation.     

Translator design to support run-time debugging

Designers and implementors of high-level language translators can, with relatively little extra effort, greatly facilitate run-time symbolic debugging. Practical suggestions are presented, based on experiences gained from interfacing several compilers with a run-time debugging system.     

Dispel: A run-time debugging language

Dispel is a language designed to aid communication between an interactive user and a run-time, symbolic debugging system. Important attributes of Dispel are that it provides a small set of primitive debugging actions, most traditional debugging aids (such as variable traces and postmortem dumps) are written in terms of these primitives as debugging routines, and Dispel serves both as an interactive debugging command language and as a special-purpose programming language. The syntax and semantics of Dispel are explained and examples of Dispel commands and routines are presented.     

The real-time debugging monitor for the bell system 1A processor

Real-time computer systems can be difficult to test when their timing characteristics influence the occurrence of problems. Because of this, tools for debugging real-time systems must account for the interference that they produce in the system they are monitoring. The debugging monitor for the Bell System 1A processor is an example of just such a tool. This paper examines the 1A processor debugging monitor, focusing on the division of the monitor into three separate devices: a hardware monitor that allows autonomous debugging; a resident monitoring program that allows debugging with a minimal interference to normal timing; and a separate mini-computer monitor that offers extended capability at the expense of unrestricted interference.     

Stabdump—a dump interpreter program to assist debugging

Program development can be greatly speeded by a dump analysis program which makes the state of a program more visible to the programmer. A single comprehensive analysis presenting as much of the relevant material in as concise a manner as possible has proved superior in use to the alternative of interactive analysis one item-at-a-time. The methods adopted in the STAB utility to achieve comprehensive and concise output are described. The system and compiler modifications necessary to support this type of system are discussed.     

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.     

JDB: An adaptable interface for debugging

In the Unix environment there are a number of debugging tools. None are universally popular and many programmers choose not to use any of them at all. In this paper we present a study of existing debuggers. We highlight a number of reasons why they may not be popular and we discuss some of the features that programmers look for in a debugging aid. Finally, we report on the development of a new screen-based interface, JDB, and some informal results of its usage.     

A simulator for real-time software debugging and testing

A software simulator can be built to facilitate debugging and testing of real-time programs. This paper describes a simulator designed to operate in three modes: simulation, debugging and process monitoring. In the simulation mode, it simulates a Z80-based microcomputer and can be used to execute programs written in the Z80-assembler language. In the debugging mode, it provides facilities for interactive debugging on the instruction level. The simulator's unique feature is the process monitoring mode. It displays the activities among processes being executed concurrently under the control of a real-time executive and thus allowing direct observation of dynamic program behaviour at the process level.     

Monitoring and debugging distributed realtime programs

In this paper we describe the design and implementation of an integrated monitoring and debugging system for a distributed real-time computer system. The monitor provides continuous, transparent monitoring capabilities throughout a real-time system's lifecycle with bounded, minimal, predictable interference by using software support. The monitor is flexible enough to observe both high-level events that are operating system- and application-specific, as well as low-level events such as shared variable references. We present a novel approach to monitoring shared variable references that provides transparent monitoring with low overhead. The monitor is designed to support tasks such as debugging realtime applications, aiding real-time task scheduling, and measuring system performance. Since debugging distributed real-time applications is particularly difficult, we describe how the monitor can be used to debug distributed and parallel applications by deterministic execution replay.     

Lazy debugging of lazy functional programs

The debugging of fully lazy functional programs can require searching a very large reduction-history space containing many delayed computations. A debugger should provide a means to obtain a source level representation of the computation, which can be large, and a means to select the appropriate part of the computation to investigate, which can be difficult. A method is presented to compile functional programs to combinator code such that a source-like representation of any part of a computation graph can be efficiently reconstructed at run-time. Other less efficient methods require excessive compile-time guidance as to the specific part of the computation to be investigated. Reconstruction, forward reduction, and a history-rollback mechanism combine to make the entire source-like reduction-history space dynamically available at run-time. The deferring of debugging decisions until run-time is called lazy dubugging. Once the computation-sequence is meaningfully and efficiently available, the problem of debugging becomes that of localizing the search for the error. Some searching issues are discussed with respect to graph browsing and user-interface design. The method shows promise as a programmer tool to debug programs and to informally reason about the time and space behavior of fully lazy functional programs, a nonintuitive process due to the subtleness of sharing and delayed computations.     

A survey on algorithmic debugging strategies

Algorithmic debugging is a debugging technique that has been extended to practically all programming paradigms. Roughly speaking, the technique constructs an internal representation of all (sub)computations performed during the execution of a buggy program; and then, it asks the programmer about the correctness of such computations. The answers of the programmer guide the search for the bug until it is isolated by discarding correct parts of the program. After twenty years of research in algorithmic debugging many different techniques have appeared to improve the original proposal. Surprisingly, no study exists that joins together all these techniques and compares their advantages and their performance. This article presents a study that compares all current algorithmic debugging techniques and analyzes their differences and their costs. The research identifies the dimensions on which each strategy relies. This information allows us to combine the strong points of different strategies.     

Java heap protection for debugging native methods

Java virtual machine (JVM) crashes are often due to an invalid memory reference to the JVM heap. Before the bug that caused the invalid reference can be fixed, its location must be identified. It can be in either the JVM implementation or the native library written in C invoked from Java applications. To help system engineers identify the location, we implemented a feature using page protection that prevents threads executing native methods from referring to the JVM heap. This feature protects the JVM heap during native method execution; if the heap is referred to invalidly, it interrupts the execution by generating a page-fault exception. It then reports the location where the exception was generated. The runtime overhead for using this feature depends on the frequency of native method calls because the protection is switched on each time a native method is called. We evaluated the runtime overhead by running the SPECjvm98, SPECjbb2000, VolanoMark, and JFCMark benchmark suites on a PC with two Intel Xeon^® 1.6 GHz processors. The performance loss was less than 2% for the benchmark items that do not call native methods so frequently (10⁴ times per second) and 5%–20% for the benchmark items that do (10⁴–10⁵ times per second). The worst performance loss was 54%, which was recorded for a benchmark item that calls native methods 2.0×10⁶ times per second.     

GPRS UDP通讯软件开发与调试

从实际产品开发的角度,描述了GPRS UDP通讯软件开发的基本内容,以及调试环境的建立等内容。     

Two unusual methods for debugging system software

This paper describes the Bug Farm, a generator of test cases for compilers, and the Bug Contest, an administrative technique for speeding the process of testing system software. The techniques achieve a high rate of bug detection while minimizing user revulsion at undebugged software.     

Solutions and debugging for data consistency in multiprocessors with noncoherent caches

We analyze two important problems that arise in shared-memory multiprocessor systems. Thestale data problem involves ensuring that data items in local memory of individual processors are current, independent of writes done by other processors.False sharing occurs when two processors have copies of the same shared data block but update different portions of the block. The false sharing problem involves guaranteeing that subsequent writes are properly combined. In modern architectures these problems are usually solved in hardware, by exploiting mechanisms for hardware controlled cache consistency. This leads to more expensive and nonscalable designs. Therefore, we are concentrating on software methods for ensuring cache consistency that would allow for affordable and scalable multiprocessing systems. Unfortunately, providing software control is nontrivial, both for the compiler writer and for the application programmer. For this reason we are developing a debugging environment that will facilitate the development of compiler-based techniques and will help the programmer to tune his or her application using explicit cache management mechanisms. We extend the notion of a race condition for IBM Shared Memory System POWER/4, taking into consideration its noncoherent caches, and propose techniques for detection of false sharing problems. Identification of the stale data problem is discussed as well, and solutions are suggested.     

Event associations in SNOBOL4 for program debugging

An event association facility for the SNOBOL4 programming language is described. This facility permits the execution of a programmer-defined function to be associated with the occurrence of a specified event. The events with which associations can be made are those applicable to program debugging. Associations can be made with events such as variable referencing, statement execution, program interruption, function call and return, and execution-time errors. By making event associations available at the source-language level, debugging aids can be written in SNOBOL4 itself, using the full capabilities of that language. As illustrated by several examples, this approach facilitates the implementation of simple yet powerful debugging aids written in the same language as the programs to be debugged. Event associations provide a mechanism for the unification of the existing SNOBOL4 debugging facilities, and a basis for the addition of other events. The implementation of event associations is also described.     

An execution-backtracking approach to debugging

Spyder, a system for selective checkpointing of computational sequences, is presented. It lets users backtrack from checkpoints without the need to reexecute the program to reach recent prior states. In contrast to more comprehensive (and storage-intensive) checkpointing schemes, backtracking in this approach is constrained to limit storage requirements. The resulting debugger offers a structured view of dynamic events, similar to lexical scope rules' effect on static visibility. The debugger also speeds backtracking to statements before loops and provides what-if capabilities     

安阳炉卷新增2号加热炉接口设计及调试

在基础自动化系统中,不同系统间的网络通讯和接口是很重要的内容,特别是对于改造项目,需要考虑和解决的问题更复杂。安钢炉卷新增2号加热炉工程是一个典型的例子,既要考虑不同系统间通讯的技术问题,还要考虑调试和生产的关系问题。本文以此为例,介绍了处理这方面问题的经验。