TL;DR: SELF's debugging system provides complete source-level debugging (expected behavior) with globally optimized code and is the first practical system providing full expected behavior with globally optimize code.
Abstract: SELF's debugging system provides complete source-level debugging (expected behavior) with globally optimized code. It shields the debugger from optimizations performed by the compiler by dynamically deoptimizing code on demand. Deoptimization only affects the procedure activations that are actively being debugged; all other code runs at full speed. Deoptimization requires the compiler to supply debugging information at discrete interrupt points; the compiler can still perform extensive optimizations between interrupt points without affecting debuggability. At the same time, the inability to interrupt between interrupt points is invisible to the user. Our debugging system also handles programming changes during debugging. Again, the system provides expected behavior: it is possible to change a running program and immediately observe the effects of the change. Dynamic deoptimization transforms old compiled code (which may contain inlined copies of the old version of the changed procedure) into new versions reflecting the current source-level state. To the best of our knowledge, SELF is the first practical system providing full expected behavior with globally optimized code.
TL;DR: An algorithm to derive the reduced flow graphs has been implemented as an extension to the recently developed system for testing and debugging (STAD 1.0) and early experiments with the algorithm are reported and potential applications in regression testing and reasoning about the program are discussed.
Abstract: It is pointed out that a major problem in software maintenance is the revalidation of a modified code. It is economically desirable to restrict that process only to those parts of the program that are affected by the modifications. Towards that goal, a formal method is needed to identify the modifications in an automatic way. Such a method is proposed in the present work. The modifications are localized within clusters in the flow graphs of the original and modified programs. Both flow graphs are transformed into reduced flow graphs, between which an isomorphic correspondence is established. Cluster-nodes in the reduced graphs encapsulate modifications to the original program. An algorithm to derive the reduced flow graphs has been implemented as an extension to the recently developed system for testing and debugging (STAD 1.0) and early experiments with the algorithm are reported. Potential applications in regression testing and reasoning about the program are discussed. >
TL;DR: This paper presents a method for semi-automatic bug localization, generalized algorithmic debugging, which has been integrated with the category partition method for functional testing, and believes that this is the first generalization of algorithmic Debugging for programs with side-effects written in imperative languages such as Pascal.
Abstract: This paper presents a method for semi-automatic bug localization, generalized algorithmic debugging, which has been integrated with the category partition method for functional testing. In this way the efficiency of the algorithmic debugging method for bug localization can be improved by using test specifications and test results. The long-range goal of this work is a semi-automatic debugging and testing system which can be used during large-scale program development of nontrivial programs.The method is generally applicable to procedural langua ges and is not dependent on any ad hoc assumptions regarding the subject program. The original form of algorithmic debugging, introduced by Shapiro, was however limited to small Prolog programs without side-effects, but has later been generalized to concurrent logic programming languages. Another drawback of the original method is the large number of interactions with the user during bug localization.To our knowledge, this is the first method which uses category partition testing to improve the bug localization properties of algorithmic debugging. The method can avoid irrelevant questions to the programmer by categorizing input parameters and then match these against test cases in the test database. Additionally, we use program slicing, a data flow analysis technique, to dynamically compute which parts of the program are relevant for the search, thus further improving bug localization.We believe that this is the first generalization of algorithmic debugging for programs with side-effects written in imperative languages such as Pascal. These improvements together makes it more feasible to debug larger programs. However, additional improvements are needed to make it handle pointer-related side-effects and concurrent Pascal programs.A prototype generalized algorithmic debugger for a Pascal subset without pointer side-effects and a test case generator for application programs in Pascal, C, dBase, and LOTUS have been implemented.
TL;DR: This paper presents an algorithmic debugger for a lazy functional language and some experience in using it, and addresses the problem of providing the user with a strictified view of the execution trace whenever possible.
Abstract: Lazy functional languages have non-strict semantics and are purely declarative, i.e. they support the notion of referential transparency and are devoid of side effects. Traditional debugging techniques are, however, not suited for lazy functional languages since computations generally do not take place in the order one might expect. Since algorithmic debugging allows the user to concentrate on the declarative aspects of program semantics, and will semi-automatically find functions containing bugs, we propose to use this technique for debugging lazy functional programs. In this paper we present an algorithmic debugger for a lazy functional language and some experience in using it. Because of the non-strict semantics of lazy functional languages, arguments to functions are in general partially evaluated expressions. The user is, however, usually more concerned with the values that these expressions represent. We address this problem by providing the user with a strictified view of the execution trace whenever possible.
TL;DR: PCN as mentioned in this paper is a programming system designed to improve the productivity of scientists and engineers using parallel supercomputers by providing a simple notation for the concise specification of concurrent algorithms, the ability to incorporate existing Fortran and C code into parallel applications, facilities for reusing parallel program components, and integrated debugging and performance analysis tools.
Abstract: We describe the PCN programming system, focusing on those features designed to improve the productivity of scientists and engineers using parallel supercomputers. These features include a simple notation for the concise specification of concurrent algorithms, the ability to incorporate existing Fortran and C code into parallel applications, facilities for reusing parallel program components, a portable toolkit that allows applications to be developed on a workstation or small parallel computer and run unchanged on supercomputers, and integrated debugging and performance analysis tools. We survey representative scientific applications and identify problem classes for which PCN has proved particularly useful.
TL;DR: App, an annotation pre-processor for C programs developed in UNIX-based development environments, has been used to develop a number of software systems over the past three years.
Abstract: Embedded assertions have long been recognized as a Po- tentially powerful tool for automatic runtime detection of software faults during debugging, testing and maintenance. Yet despite the richness of the notations and the maturity of the techniques and tools that have been developed for programming with assertions, assertions are a development tool that has seen little widespread use in practice. The main reasons seem to be that (1) previous assertion processing tools did not integrate easily with existing programming environments, and (2) it is not well understood what kinds of assertions are most effective at detecting software faults. This paper describes experience using an assertion processing tool that was built to address the concerns of ease-of-use and effectiveness. The tool is called App, an Annotation Pre- Processor for C programs developed in UNIX-based de- velopment environments. APP has been used to develop a number of software systems over the past three years Based on this experience, the paper presents a classification of the assertions that were most effective at detecting faults. While the assertions that are described guard against many common kinds of faults and errors, the very commonness of such faults demonstrates the need for an explicit, high-level, automatically check-able specification of required behavior. It is hoped that the classification presented in this paper will prove to be a useful first step in developing a method of programming with assertions.
TL;DR: It is argued that until random testing of a million points becomes practical, testing for quality is only a poor competitor for other heuristic defect-detection methods.
Abstract: The relationship between software testing and reliability is discussed. Two kinds of reliability models, reliability-growth models, which are applied during debugging, and reliability models, which are applied after debugging, are described. Several reasons for the failure of conventional reliability theory in software engineering are presented. It is argued that until random testing of a million points becomes practical, testing for quality is only a poor competitor for other heuristic defect-detection methods. >
TL;DR: Run‐time checking of array subscripts and pointer bounds was added to the Portable C Compiler (PCC) and has found latent bugs and the cause of intermittent core dumps in programs used for many years by thousands of people.
Abstract: Run-time checking of array subscripts and pointer bounds was added to the Portable C Compiler (PCC). Memory overwrite bugs are then caught as they happen instead of when the overwritten memory is used later in the program execution. The run-time checking compiler is used both to find the true cause of a core dump and to eliminate run-time errors as the cause of unexpected program behavior. On average, it takes about 40 percent longer to compile, the generated code is about three times larger, and it runs about ten times slower. This performance may seem slow, but it typically reduces days of debugging to less than an hour. The implementation described herein can be adapted to any C compiler as it describes how to generate run-time checking code in a machine/compiler independent way by changing the intermediate expression trees. In four years of use it has found latent bugs and the cause of intermittent core dumps in programs used for many years by thousands of people.
TL;DR: This paper describes how the monitor can be used to debug distributed and parallel applications by deterministic execution replay and presents a novel approach to monitoring shared variable references that provides transparent monitoring with low overhead.
Abstract: 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.
TL;DR: A new compiler-debugger interfaces (CDI) was designed that supports providing visual feedback and the debugging of optimized code and relates each feature back to the debugger functionality it supports.
Abstract: Debugging optimized code is a desirable capability not provided by most current debuggers. Users are forced to debug the unoptimized code when a bug occurs in the optimized version. Current research offers partial solutions for a small class of optimizations, but not a unified approach that handles a wide range of optimizations, such as the sophisticated optimizations performed by supercomputer compilers.The trend with current research is to make the effects of optimization transparent, i.e., provide the same behavior as that of the unoptimized program. We contend that this approach is neither totally feasible nor entirely desirable. Instead, we propose a new approach based on the premise that one should be able to debug the optimized code. This implies mapping the current state of execution back to the original source, tracking the location of variables, and mapping compiler-synthesized variables back to user-defined induction variables. To aid the user in understanding program behavior, various visual means are provided, e.g., different forms of highlighting and annotating of the source/assembly code. While this unavoidably requires the user to have a basic understanding of the optimizations performed, it permits the user to see what is actually happening, infer the optimizations performed, and detect bugs. An example illustrates the effectiveness of visual feedback.To support conventional debugger functionality for optimized code, the compiler must generate additional information. Current compiler-debugger interfaces (CDIs) were neither designed to handle this new information nor are they extensible in a straight forward manner. Therefore, a new CDI was designed that supports providing visual feedback and the debugging of optimized code. This paper specifies the details of a new CDI and relates each feature back to the debugger functionality it supports.
TL;DR: An overview of Paralex is given and the experiences with a prototype implementation are presented, aimed at exploring the extent to which the parallel application programmer can be liberated from the complexities of distributed systems.
Abstract: Modern distributed systems consisting of powerful workstations and high-speed interconnection networks are an economical alternative to special-purpose super computers. The technical issues that need to be addressed in exploiting the parallelism inherent in a distributed system include heterogeneity, high-latency communication, fault tolerance and dynamic load balancing. Current software systems for parallel programming provide little or no automatic support towards these issues and require users to be experts in fault-tolerant distributed computing. The Paralex system is aimed at exploring the extent to which the parallel application programmer can be liberated from the complexities of distributed systems. Paralex is a complete programming environment and makes extensive use of graphics to define, edit, execute and debug parallel scientific applications. All of the necessary code for distributing the computation across a network and replicating it to achieve fault tolerance and dynamic load balancing is automatically generated by the system. In this paper we give an overview of Paralex and present our experiences with a prototype implementation.
TL;DR: Initial experience indicates that PSpec is a useful tool for performance testing and debugging; it helped uncover several performance bugs in the runtime system of a parallel programming language.
Abstract: Performance assertion checking is an approach to automating the testing of performance properties of complex systems. System designers write assertions that capture expectations for performance; these assertions are checked automatically against monitoring data to detect potential performance bugs. Automatically checking expectations allows a designer to test a wide range of performance properties as a system evolves: data that meets expectations can be discarded automatically, focusing attention on data indicating potential problems.PSpec is a language for writing performance as sertions together with tools for testing assertions and estimating values for constants in assertions. The language is small and efficiently checkable, yet capable of expressing a wide variety of performance properties. Initial experience indicates that PSpec is a useful tool for performance testing and debugging; it helped uncover several performance bugs in the runtime system of a parallel programming language.
TL;DR: An abstract framework based on global snapshots is proposed, which is defined to form a consistent state of the entire system, and shown that by using a property preserving algorithm, this framework can be superimposed on the underlying computation, but not interfere with it.
Abstract: The widespread adoption of distributed computing has accentuated the need for an effective set of support tools to facilitate debugging and monitoring. In providing such support, one fundamental problem is that of constructing a global snapshot or global state of a distributed computation. This paper examines global snapshot algorithms from a distributed debugging perspective, and proposes an abstract framework based on global snapshots, which is defined to form a consistent state of the entire system. It is shown that by using a property preserving algorithm, this framework can be superimposed on the underlying computation, but not interfere with it. >
TL;DR: In this article, a debugger for a computer-based discrete-event simulation model of systems having parallel processes includes a run-time graphic user interface module in which predefined events of the executing simulation model are animated, and a runtime interface simulator module for controlling execution of the simulation model based on commands from the graphical user interface.
Abstract: A graphical, interactive debugger for a computer-based discrete-event simulation model of systems having parallel processes includes a run-time graphic user interface module in which predefined events of the executing simulation model are animated, and a run-time interface simulator module for controlling execution of the simulation model based on commands from the graphical user interface. The model and the animation are based on hierarchical directed process execution graphs in which a transaction represents one of several processes executing in parallel within the system modeled with the graphs. One transaction at a time is shown moving between nodes in one of the graphs. The animation follows the transaction as it moves between sub-models represented by each graph, switching to other graphs as needed. Once the transaction is blocked, the next transaction is displayed in context of the appropriate graph and followed until it is blocked. The screen on which animation is presented is divided into two areas. One provides the animation, the other displays the text of trace messages generated by the executing simulation model and on which the animation is based. The animation may be selectively limited to user-specified events, transactions or sub-models, providing detailed probing of the model for purposes of debugging.
TL;DR: A system, called Cake, is described that comprises seven layers of knowledge representation and reasoning facilities: truth maintenance, Boolean constraint propagation, equality, types, algebra, frames, and Plan Calculus.
Abstract: The authors' experience in the Programmer's Apprentice project in applying knowledge representation and automated reasoning to support software development is summarized. A system, called Cake, is described that comprises seven layers of knowledge representation and reasoning facilities: truth maintenance, Boolean constraint propagation, equality, types, algebra, frames, and Plan Calculus. Sessions with two experimental software development tools implemented using Cake, the Requirements Apprentice and the Debugging Assistant, are also included. >
TL;DR: In this article, a column reference is added to debugging information generated in connection with an object module to distinguish the different statements in a line of a computer program, and alternative means for specifying the statement are also described.
Abstract: A method and apparatus for statement level debugging. Statement level debugging refers to the ability to identify a statement in a source file, i.e. a breakpoint, and have program execution suspended at that point. Further, "stepping" through the execution of the program may be performed a statement at a time. In accomplishing this a column reference is added to debugging information generated in connection with an object module. The column reference provides for distinguishing the different statements in a line of a computer program. Statement level debugging allows for more precise control of the debugging of a program. Alternative means for specifying the statement are also described.
TL;DR: SELF's debugging system provides complete source-level debugging (expected behavior) with globally optimized code with global optimized code.
Abstract: SELF's debugging system provides complete source-level debugging (expected behavior) with globally optimized code. It shields the debugger from optimizations performed by the compiler by dynamicall...
TL;DR: The interprocedural dynamic slicing introduced in this paper is being used to improve the bug localization properties of the Generalized Algorithmic Debugging Technique [FGKS91], a method for declarative semi-automatic debugging.
Abstract: This paper presents the first algorithm for interprocedural dynamic slicing. Previous methods for dynamic slicing only considered languages without procedures and procedure calls. This method generates summary information for each procedure call and represents a program as a summary graph of dynamic dependencies. A slice on this graph consists of nodes for all procedure calls of the program that affect the value of a given variable. The size of the information saved by this method is considerably smaller than what is needed by previous methods for dynamic slicing [AH90], since it only depends on the size of the program's execution tree, i.e. the number of executed procedure calls, which is much smaller than the size of a trace of all executed statements. In addition, work space for the temporary graph is needed, proportional to the maximum sum of the sizes of simultaneously active procedures. A program slice can be produced from the interprocedural slice on the graph if a suitable definition of control dependency is used when the summary graph is constructed. The interprocedural dynamic slicing introduced in this paper is being used to improve the bug localization properties of the Generalized Algorithmic Debugging Technique [FGKS91], a method for declarative semi-automatic debugging.
TL;DR: In this paper, a program debugging system for a distributed data processing system of the type in which a plurality of processes communicate with one another to realize their concurrent and parallel operations is presented.
Abstract: A program debugging system for a distributed data processing system of the type in which a plurality of processes communicate with one another to realize their concurrent and parallel operations. The debugging system includes a plurality of satellite debugging units, coupled respectively with the plurality of processes, for debugging the processes; a central debugging unit for remotely controlling the plurality of satellite debugging units; and a remote-procedure-call detecting unit for previously detecting an issuance or an end of a remote procedure call in the process to be debugged by the satellite debugging units. In the debugging system, each of the satellite debugging units includes an execution interrupting unit for interrupting the execution of the process to be debugged and transmitting a message of the execution-interruption to the central debugging unit; an execution restarting unit for restarting the execution of the interrupted process and transmitting a message of the execution-restart to the central debugging unit; an interruption-time notifying unit for calculating an execution-interruption time on the basis of the interruption and restart of the execution of the process and for transmitting the calculated interruption time to the central debugging unit; and an execution delay unit for delaying, when the remote-procedure-call detecting unit detects the issuance of a remote procedure call by a process, the execution of the remote procedure call according to information including the execution-interruption time of another process that is transmitted from the central debugging unit.
TL;DR: The main conclusion of this work is that software-configurable hardware approaches to high speed digital signal processing problems form viable alternatives to existing approaches, for systems designers interested in rapidly prototyping or implementing their ideas.
Abstract: The high throughput (computation) requirements of real-time digital signal processing (scDSP) systems usually dictate hardware intensive solutions. Often attendant to hardware approaches are problems of high development costs, slow turnaround, susceptibility to errors, and difficulty in testing and debugging, all of which tend to inhibit the rapid implementation of such systems. Research is underway into the synthesis of application specific hardware to aid the system designer by automatically generating hardware that is "correct by construction". The creation of configurable, pre-fabricated hardware that has been designed for high speed computations forms part of this research and is the main topic of this thesis.
This work contains a survey of some typical real-time scDSP algorithms drawn from video and speech processing and summarizes the particular computation challenges posed by this class of algorithms. Currently available hardware choices and their trade-offs and limitations are discussed. A multiprocessor architecture consisting of programmable arithmetic devices is presented as a novel platform for supporting high speed digital signal processing. The scVLSI realization of the architecture and an accompanying software development environment are presented as a proof of concept. The main conclusion of this work is that software-configurable hardware approaches to high speed digital signal processing problems form viable alternatives to existing approaches, for systems designers interested in rapidly prototyping or implementing their ideas.
TL;DR: In this article, a technique for tracing and replaying message-passing programs for debugging is presented, where runtime decisions are used to detect and trace only those messages that introduce nondeterminacy.
Abstract: A techinque for tracing and replaying message-passing programs for debugging is presented The technique is optimal in the common case and has good performance in the worst case By making runtime tracing decisions, only a fraction of the total number of messages is traced, gaining two orders of magnitude reduction over traditional techniques which trace every message Experiments indicate that only 1% of the messages often need to be traced These traces are sufficient to provide replay, allowing an execution to be reproduced any number of times for debugging This work is novel in that runtime decisions are used to detect and trace only those messages that introduce nondeterminacy With the proposed strategy, large reductions in trace size allow long-running programs to be replayed that were previously unmanageable In addition, the reduced tracing experiments alleviate tracing bottlenecks, allowing executions to be debugged with substantially lower execution-time overhead
TL;DR: The purpose and use of the HeNCE software is described, which provides a graphical interface for creating, compiling, executing, and debugging parallel programs, as well as configuring a distributed virtual computer (using PVM).
Abstract: HeNCE (heterogeneous network computing environment) is an X Window based graphical parallel programming environment that was created to assist scientists and engineers with the development of parallel programs. HeNCE provides a graphical interface for creating, compiling, executing, and debugging parallel programs, as well as configuring a distributed virtual computer (using PVM). HeNCE programs can be run on a single Unix workstation or over a network of heterogeneous machines. The paper describes the purpose and use of the HeNCE software. >
TL;DR: A system called AVPGEN, which uses such techniques for debugging high-level machine designs and has already proved useful in finding errors, is described, which consists of a generator and a symbolic simulator.
Abstract: The use of constraint solving and symbolic execution to generate highly probing test cases is discussed. A system called AVPGEN, which uses such techniques for debugging high-level machine designs and has already proved useful in finding errors, is described. AVPGEN generates large numbers of architecture verification programs. It consists of a generator and a symbolic simulator. The generator uses constraint solving, symbolic values and undo capabilities to set up conditions. These conditions may be architecture specific or design specific. The simulator in AVPGEN, although not bug-free, is considerably simpler than any of the hardware implementations it is used to verify. >
TL;DR: The optimum time to stop software testing such that software reliability is maximized without exceeding the cost budget for testing and debugging is determined.
TL;DR: The author presents a new technique, the don't-care propagation method, for logic verification and design error location in a circuit that has very high resolution and reduces the debugging time by the designers.
Abstract: The author presents a new technique, the don't-care propagation method, for logic verification and design error location in a circuit. Test patterns for single stuck-line faults are used to compare the gate-level implementation of a circuit with its functional-level specification. In the presence of logic design errors, such a test set will produce responses in the implementation that disagree with the responses in the specification. In the verification phase of the design of logic circuits using the top-down approach, it is necessary not only to detect but also to locate the source of any inconsistency that may exist between the specification and the implementation. This technique can determine the region containing the error. It has very high resolution and reduces the debugging time by the designers. Extensive experimental results were obtained to demonstrate the effectiveness of the new approach. >
TL;DR: In this paper, a system is provided for debugging code in each domain as part of said multi-code executing and debugging system in a multi-architecture environment. But the debugging system includes means for receiving calls for debugger operation from either the X domain or the Y domain.
Abstract: In a computer system that embodies a first hardware (X) architecture and includes a memory system and at least one simulator for a second (Y) architecture and a system for executing and debugging multiple codes having an environment manager that handles cross-domain calls, a system is provided for debugging code in each domain as part of said multi-code executing and debugging system in a multi-architecture environment. The debugging system includes means for receiving calls for debugger operation from either the X domain or the Y domain. Commands are generated for debugging operations in either domain. The commands that may be generated by the user include RUN and STEP commands for the machine state in the debug domain. General support commands and debug operations support commands may also be generated. The debug operations support commands include EXAMINE, DEPOSIT, SET BREAKPOINT AND CANCEL BREAKPOINT. The latter commands are implemented differently for the different domains.
TL;DR: An overview of the Dynascope system is given and sample applications are presented: debugging register allocation, animation of procedure calls, and a complex artificial life simulation.
Abstract: This paper introduces program directing, a new way of program interaction. Directing enables one program, the director, to monitor and to control another program, the executor. One important application of program directing is human interaction with complex computer simulations.The Dynascope programming environment is designed specifically to support directing in traditional, compiled languages. It provides a framework and building blocks for easy construction of sophisticated directors. Directors are regular programs that perform the directing of executors through Dynascope primitives. Dynascope is built around the concept of the execution stream which provides a complete description of the executor's computational behavior. The source code of executors requires no changes in order to be subjected to directing.This paper gives an overview of the Dynascope system. Sample applications are presented: debugging register allocation, animation of procedure calls, and a complex artificial life simulation. The performance of Dynascope is illustrated by real time measurements.
TL;DR: Methods and tools for detecting nondeterminacy in programs for shared-memory multiprocessors, including those that statically analyze the source program and those that analyze an execution trace of the program, are discussed.
Abstract: 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. >
TL;DR: It is proved that, for executions using synchronization powerful enough to implement two-process mutual exclusion, locating every general race or data race is an NP-hard problem, and it is shown that detecting only a subset of all races is sufficient for debugging, and post-mortem algorithms for detecting race conditions as accurately as possible are presented.
Abstract: This thesis addresses theoretical and practical aspects of the dynamic detecting and debugging of race conditions in shared-memory parallel programs. To reason about race conditions, we present a formal model that characterizes actual, observed, and potential behaviors of the program. The actual behavior precisely represents the program execution, the observed behavior represents partial information that can be reasonably recorded, and the potential behavior represents alternate executions possibly allowed by nondeterministic timing variations. These behaviors are used to characterize different types of race conditions, general races and data races, which pertain to different classes of parallel programs and require different detection techniques. General races apply to programs intended to be deterministic; data races apply to nondeterministic programs containing critical sections.
We prove that, for executions using synchronization powerful enough to implement two-process mutual exclusion, locating every general race or data race is an NP-hard problem. However, for data races, we show that detecting only a subset of all races is sufficient for debugging. We also prove that, for weaker types of synchronization, races can be efficiently located.
We present post-mortem algorithms for detecting race conditions as accurately as possible, given the constraint of limited run-time information. We characterize those races that are direct manifestations of bugs and not artifacts caused by other races, imprecise run-time traces (causing false races to appear real), or unintentional synchronization (caused by shared-memory references). Our techniques analyze the observed behavior to conservatively locate races that either did occur or had the potential of occurring, and that were unaffected by any other race in the execution.
Finally, we describe a prototype data race detector that we used to analyze a sample collection of parallel programs. Experiments indicate that our techniques effectively pinpoint non-artifact races, directing the programmer to parts of the execution containing direct manifestations of bugs. In all programs analyzed, our techniques reduced hundreds to thousands of races down to four or fewer that required investigation.
TL;DR: Synchronization of an architectural model of a computer architecture and a behavioral model of an implementation of the architecture for functional verification of the implementation is discussed in this article, where a communication channel is established between the two models through which simulation control and state information can be communicated and both models are available for simulating.
Abstract: Synchronization of an architectural model of a computer architecture and a behavioral model of an implementation of the architecture for functional verification of the implementation. A communication channel is established between the two models through which simulation control and state information can be communicated and both models are available for simulating. Synchronization points in the models' executions are identified, and a synchronizer is implemented which instructs each model to simulate to a synchronization point and report relevant state information. The synchronizer can also verify state information from the two models in real time, flag errors, or instruct the architectural model to modify its state either to match known errors in the behavioral model or to match correct behavior to an asynchronous event.