The main problems associated with debugging concurrent programs are increased complexity, the “probe effect, ” nonrepeatability, and the lack of a synchronized global clock. The probe effect refers to the fact that any attempt to observe the behavior of a distributed system may change the behavior of that system. For some parallel programs,

Testing is an important part of any software development project, and can typically surpass more than half of the development cost. For safety-critical computer based systems, testing is even more important due to stringent reliability and safety requirements. However, most safety-critical computer based systems are real-time systems, and the majority of current testing and debugging techniques have been developed for sequential (non real-time) programs. These techniques are not directly applicable to real-time systems, since they disregard issues of timing and concurrency. This means that existing techniques for reproducible testing and debugging cannot be used. Reproducibility is essential for regression testing and cyclic debugging, where the same test cases are run repeatedly with the intention of verifying modified program code or to track down errors. The current trend of consumer and industrial applications goes from single microcontrollers to sets of distributed micro-controllers, which are even more challenging than handling real-time per-see, since multiple loci of observation and control additionally must be considered. In this thesis we try to remedy these problems by presenting an integrated approach to monitoring, testing, and debugging of distributed real-time systems. For monitoring

pSather is a parallel extension of the existing object-oriented language Sather. It offers a shared-memory programming model which integrates both control- and dataparallel extensions. This integration increases the flexibility of the language to express different algorithms and data structures, especially on distributed-memory machines (e.g. CM-5). This report describes our design objectives and the programming language pSather in detail. ICSI and Eidgenossische Technische Hochschule (ETH), Zurich, Switzerland. E-mail: murer@icsi.berkeley.edu. y ICSI and Computer Science Division, U.C. Berkeley. E-mail: jfeldman@icsi.berkeley.edu. z ICSI and Computer Science Division, U.C. Berkeley. E-mail: clim@icsi.berkeley.edu. x ICSI E-mail: mseidel@icsi.berkeley.edu. ii Contents 1 Introduction 4 1.1 Roadmap of this Report : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 1.2 Grammar Notation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 6 2...

In this State of the art Report (SotA), we will give an introduction to work presented in the area of debugging large software systems with modern hardware architectures. We will discuss techniques used for single- multi- and distributed systems. In addition we will provide pointers to work by large players in the field, and major conferences of importance.

A good design, development, and maintenance methodology for concurrent systems must be based on a good recognition and/or understanding of the intrinsic characteristics of concurrent systems. Measuring and monitoring the behavior of a complex concurrent system is an indispensable way to achieve the reliability of the system. Based on recognition and/or understanding of the wholeness principle of concurrent systems and the uncertainty principle in measuring and monitoring concurrent systems, this paper proposes a new design principle, named the "self-measurement principle," for large-scale, long-lived, and highly reliable concurrent systems. The self-measurement principle requires that a large-scale, long-lived, and highly reliable concurrent system should be constructed by some function components and some (maybe only one) permanent selfmeasurement components that act concurrently with the function components, measure and monitor the system itself according to some requirements, and pa...

In order to test, or debug, a system we must observe its run-time behavior and deem how well the observations comply with the system requirements. There are two significant differences between debugging and testing of software for desktop computers and embedded real-time systems: (1) It is more difficult to observe embedded computer systems, simply because they are embedded, and that they thus have very few interfaces to the outside world, and (2) the actual act of observing a real-time systems or distributed real-time system can change their behavior. Monitoring of sequential software is straightforward, but for distributed realtime systems it is more complicated, since race conditions with respect to order of access to shared resources occur naturally. Any intrusive observation, or probing, of the distributed real-time system affects the timing and consequently the outcome of the races. In this paper we present a method for deterministic observations of single tasking, multi-taskin...

Nondeterminacy implies two unpleasant properties for testing and debugging parallel programs: successive executions of the same program with the same input values often do not show identical behaviour and watching the program influences the execution. It is therefore not always possible to test and debug parallel programs like sequential ones. This article presents an approach how to make test, regression test and cyclic debugging as easy as in the sequential case. To meet this goal we provide the user with the ability to specify not only input data for tests, but also the sequence of interprocess communications. This also guarantees reproducibility for debugging and regression testing. 1 Introduction Massively parallel systems gain more and more success in commercial markets and try to deal with the Grand Challenges [GC92]. But despite all success it is still hard to exploit the available computing power of these systems. Besides the fact that design and coding of parallel pro...

A smart transducer netsyork consists of a set of transducer nodes interconnected witit a digital bus. Smart transducer technology implicates the development of systems supporting the timely exchange of real-time data. Additional requirements are support for system integration, mechanisms for dynamic reconfiguration, and diagnostic interfaces. Such systems should be compoxable and ease controlling system complexity, i.e. support the system engineer in understanding the system behavior.

. We present a general trace query language which is a solution to the ever growing command sets of other tracers. It provides all the required generality while being very simple and efficient. We model a program execution into a trace which is a stream of events. Execution events have a uniform representation, and can be analysed by Prolog programs. With this approach and thanks to the expressive power of Prolog, two high-level primitives plus Prolog are enough to provide a general trace query language. With a few optimizations this language can work on large executions without any loss of performance, if compared to traditional tracers. This paper describes the trace query mechanism from its high level specification down to some implementation details. The proposed model of trace query depends only on the sequentiality of the execution, and the principles behind the design of the optimizations do not depend on the traced language. 1 Introduction While debugging, program...

views of executions are the basis for a trace browser. 2.1 A trace query language based on Prolog We model an execution into a trace which is a stream of events. Execution events have a uniform representation, and can be analysed by programs. At a conceptual level, only two tracing primitives are necessary to retrieve trace information on the fly: one to retrieve the information related to the current event, another one to retrieve ? in, G. Comyn and N. Fuchs editors, Proceedings of the Second Logic Programming Summer School, September 1992, Zurich. Springer-Verlag, Lecture Notes in Artificial Intelligence 636. ??? Author's current address: IRISA/INSA, Campus Universitaire de Beaulieu, F-35042 Rennes, email: ducasse@irisa.fr information related to the next event. A trace can be considered as a history of execution events, and the two primitives can be matched on the notions of today (current event) and tomorrow (next event). These two primitives, plus Prolog, make a powerful tra...