Search NASA⌕ Search

SEARCH · Search NASA

Results for “data races”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2003

High-Level Data Races

Data races are a common problem in concurrent and multi-threaded programming. They are hard to detect without proper tool support. Despite the successful application of these tools, experience shows that the notion of data race is not powerful enough to capture certain types of inconsistencies occurring in practice. In this paper we investigate data races on a higher abstraction layer. This enables us to detect inconsistent uses of shared variables, even if no classical race condition occurs. For example, a data structure representing a coordinate pair may have to be treated atomically. By lifting the meaning of a data race to a higher level, such problems can now be covered. The paper defines the concepts view and view consistency to give a notation for this novel kind of property. It describes what kinds of errors can be detected with this new definition, and where its limitations are. It also gives a formal guideline for using data structures in a multi-threading environment.

Artho, Cyrille↗
NASA NTRS2002

Program Instrumentation and Trace Analysis

Several attempts have been made recently to apply techniques such as model checking and theorem proving to the analysis of programs. This shall be seen as a current trend to analyze real software systems instead of just their designs. This includes our own effort to develop a model checker for Java, the Java PathFinder 1, one of the very first of its kind in 1998. However, model checking cannot handle very large programs without some kind of abstraction of the program. This paper describes a complementary scalable technique to handle such large programs. Our interest is turned on the observation part of the equation: How much information can be extracted about a program from observing a single execution trace? It is our intention to develop a technology that can be applied automatically and to large full-size applications, with minimal modification to the code. We present a tool, Java PathExplorer (JPaX), for exploring execution traces of Java programs. The tool prioritizes scalability for completeness, and is directed towards detecting errors in programs, not to prove correctness. One core element in JPaX is an instrumentation package that allows to instrument Java byte code files to log various events when executed. The instrumentation is driven by a user provided script that specifies what information to log. Examples of instructions that such a script can contain are: 'report name and arguments of all called methods defined in class C, together with a timestamp'; 'report all updates to all variables'; and 'report all acquisitions and releases of locks'. In more complex instructions one can specify that certain expressions should be evaluated and even that certain code should be executed under various conditions. The instrumentation package can hence be seen as implementing Aspect Oriented Programming for Java in the sense that one can add functionality to a Java program without explicitly changing the code of the original program, but one rather writes an aspect and compiles it into the original program using the instrumentation. Another core element of JPaX is an observation package that supports the analysis of the generated event stream. Two kinds of analysis are currently supported. In temporal analysis the execution trace is evaluated against formulae written in temporal logic. We have implemented a temporal logic evaluator on finite traces using the Maude rewriting system from SRI International, USA. Temporal logic is defined in Maude by giving its syntax as a signature and its semantics as rewrite equations. The resulting semantics is extremely efficient and can handle event streams of hundreds of millions events in few minutes. Furthermore, the implementation is very succinct. The second form of even stream analysis supported is error pattern analysis where an execution trace is analyzed using various error detection algorithms that can identify error-prone programming practices that may potentially lead to errors in some different executions. Two such algorithms focusing on concurrency errors have been implemented in JPaX, one for deadlocks and the other for data races. It is important to note, that a deadlock or data race potential does not need to occur in order for its potential to be detected with these algorithms. This is what makes them very scalable in practice. The data race algorithm implemented is the Eraser algorithm from Compaq, however adopted to Java. The tool is currently being applied to a code base for controlling a spacecraft by the developers of that software in order to evaluate its applicability.

Havelund, Klaus↗
NASA NTRS2004

Using Block-local Atomicity to Detect Stale-value Concurrency Errors

Data races do not cover all kinds of concurrency errors. This paper presents a data-flow-based technique to find stale-value errors, which are not found by low-level and high-level data race algorithms. Stale values denote copies of shared data where the copy is no longer synchronized. The algorithm to detect such values works as a consistency check that does not require any assumptions or annotations of the program. It has been implemented as a static analysis in JNuke. The analysis is sound and requires only a single execution trace if implemented as a run-time checking algorithm. Being based on an analysis of Java bytecode, it encompasses the full program semantics, including arbitrarily complex expressions. Related techniques are more complex and more prone to over-reporting.

Artho, Cyrille↗
NASA NTRS2008

RACER: Effective Race Detection Using AspectJ

The limits of coding with joint constraints on detected and undetected error rates Programming errors occur frequently in large software systems, and even more so if these systems are concurrent. In the past, researchers have developed specialized programs to aid programmers detecting concurrent programming errors such as deadlocks, livelocks, starvation and data races. In this work we propose a language extension to the aspect-oriented programming language AspectJ, in the form of three new built-in pointcuts, lock(), unlock() and may be Shared(), which allow programmers to monitor program events where locks are granted or handed back, and where values are accessed that may be shared amongst multiple Java threads. We decide thread-locality using a static thread-local objects analysis developed by others. Using the three new primitive pointcuts, researchers can directly implement efficient monitoring algorithms to detect concurrent programming errors online. As an example, we expose a new algorithm which we call RACER, an adoption of the well-known ERASER algorithm to the memory model of Java. We implemented the new pointcuts as an extension to the Aspect Bench Compiler, implemented the RACER algorithm using this language extension and then applied the algorithm to the NASA K9 Rover Executive. Our experiments proved our implementation very effective. In the Rover Executive RACER finds 70 data races. Only one of these races was previously known.We further applied the algorithm to two other multi-threaded programs written by Computer Science researchers, in which we found races as well.

data analysis↗
NASA NTRS2002

An Overview of the Runtime Verification Tool Java PathExplorer

We present an overview of the Java PathExplorer runtime verification tool, in short referred to as JPAX. JPAX can monitor the execution of a Java program and check that it conforms with a set of user provided properties formulated in temporal logic. JPAX can in addition analyze the program for concurrency errors such as deadlocks and data races. The concurrency analysis requires no user provided specification. The tool facilitates automated instrumentation of a program's bytecode, which when executed will emit an event stream, the execution trace, to an observer. The observer dispatches the incoming event stream to a set of observer processes, each performing a specialized analysis, such as the temporal logic verification, the deadlock analysis and the data race analysis. Temporal logic specifications can be formulated by the user in the Maude rewriting logic, where Maude is a high-speed rewriting system for equational logic, but here extended with executable temporal logic. The Maude rewriting engine is then activated as an event driven monitoring process. Alternatively, temporal specifications can be translated into efficient automata, which check the event stream. JPAX can be used during program testing to gain increased information about program executions, and can potentially furthermore be applied during operation to survey safety critical systems.

Havelund, Klaus↗
NASA NTRS2001

Monitoring Java Programs with Java PathExplorer

We present recent work on the development Java PathExplorer (JPAX), a tool for monitoring the execution of Java programs. JPAX can be used during program testing to gain increased information about program executions, and can potentially furthermore be applied during operation to survey safety critical systems. The tool facilitates automated instrumentation of a program's late code which will then omit events to an observer during its execution. The observer checks the events against user provided high level requirement specifications, for example temporal logic formulae, and against lower level error detection procedures, for example concurrency related such as deadlock and data race algorithms. High level requirement specifications together with their underlying logics are defined in the Maude rewriting logic, and then can either be directly checked using the Maude rewriting engine, or be first translated to efficient data structures and then checked in Java.

Havelund, Klaus↗
DOE OSTI2025

Scabbard

Scabbard is a tool to detect data races that occur between AMD GPUs and CPUs, for projects using HIP technology. The tool detects unsynchronized memory accesses when using unified memory. It is designed as an extension of LLVM/clang for ROCm.

Laguna Peralta, Ignacio [Lawrence Livermore Nation↗
NASA NTRS1991

LLNL contributions to MPD thrusters for SEI

Some of the topics covered with respect to the Lawrence Livermore National Laboratory's (LLNL's) contributions to Magnetoplasmadynamic (MPD) Thrusters for the Space Exploration Initiative (SEI) include: an IR camera, plasma-induced erosion/redeposition, the Mirror Fusion Test Facility-B (MFTF-B), the Thruster Lifetime Test Facility, the RACE Compact Torus Accelerator Facility, and a RACE program summary. Some of the other topics addressed include: flux contours for HAM simulation, comparison of RACE data of plasma ring formation with the HAM 2-D magnetohydrodynamic code, and the 2-D Ring Acceleration Code (TRAC).

Hooper, Edwin Bickford↗
NASA NTRS1993

The ParaScope parallel programming environment

The ParaScope parallel programming environment, developed to support scientific programming of shared-memory multiprocessors, includes a collection of tools that use global program analysis to help users develop and debug parallel programs. This paper focuses on ParaScope's compilation system, its parallel program editor, and its parallel debugging system. The compilation system extends the traditional single-procedure compiler by providing a mechanism for managing the compilation of complete programs. Thus, ParaScope can support both traditional single-procedure optimization and optimization across procedure boundaries. The ParaScope editor brings both compiler analysis and user expertise to bear on program parallelization. It assists the knowledgeable user by displaying and managing analysis and by providing a variety of interactive program transformations that are effective in exposing parallelism. The debugging system detects and reports timing-dependent errors, called data races, in execution of parallel programs. The system combines static analysis, program instrumentation, and run-time reporting to provide a mechanical system for isolating errors in parallel program executions. Finally, we describe a new project to extend ParaScope to support programming in FORTRAN D, a machine-independent parallel programming language intended for use with both distributed-memory and shared-memory parallel computers.

Cooper, Keith D.↗
NASA NTRS2001

Using Runtime Analysis to Guide Model Checking of Java Programs

This paper describes how two runtime analysis algorithms, an existing data race detection algorithm and a new deadlock detection algorithm, have been implemented to analyze Java programs. Runtime analysis is based on the idea of executing the program once. and observing the generated run to extract various kinds of information. This information can then be used to predict whether other different runs may violate some properties of interest, in addition of course to demonstrate whether the generated run itself violates such properties. These runtime analyses can be performed stand-alone to generate a set of warnings. It is furthermore demonstrated how these warnings can be used to guide a model checker, thereby reducing the search space. The described techniques have been implemented in the b e grown Java model checker called PathFinder.

Havelund, Klaus↗
NASA NTRS2001

Java PathExplorer: A Runtime Verification Tool

We describe recent work on designing an environment called Java PathExplorer for monitoring the execution of Java programs. This environment facilitates the testing of execution traces against high level specifications, including temporal logic formulae. In addition, it contains algorithms for detecting classical error patterns in concurrent programs, such as deadlocks and data races. An initial prototype of the tool has been applied to the executive module of the planetary Rover K9, developed at NASA Ames. In this paper we describe the background and motivation for the development of this tool, including comments on how it relates to formal methods tools as well as to traditional testing, and we then present the tool itself.

Havelund, Klaus↗
NASA NTRS2003

Experiments with Test Case Generation and Runtime Analysis

Software testing is typically an ad hoc process where human testers manually write many test inputs and expected test results, perhaps automating their execution in a regression suite. This process is cumbersome and costly. This paper reports preliminary results on an approach to further automate this process. The approach consists of combining automated test case generation based on systematically exploring the program's input domain, with runtime analysis, where execution traces are monitored and verified against temporal logic specifications, or analyzed using advanced algorithms for detecting concurrency errors such as data races and deadlocks. The approach suggests to generate specifications dynamically per input instance rather than statically once-and-for-all. The paper describes experiments with variants of this approach in the context of two examples, a planetary rover controller and a space craft fault protection system.

Artho, Cyrille↗
NASA NTRS2003

Instrumentation of Java Bytecode for Runtime Analysis

This paper describes JSpy, a system for high-level instrumentation of Java bytecode and its use with JPaX, OUT system for runtime analysis of Java programs. JPaX monitors the execution of temporal logic formulas and performs predicative analysis of deadlocks and data races. JSpy s input is an instrumentation specification, which consists of a collection of rules, where a rule is a predicate/action pair The predicate is a conjunction of syntactic constraints on a Java statement, and the action is a description of logging information to be inserted in the bytecode corresponding to the statement. JSpy is built using JTrek an instrumentation package at a lower level of abstraction.

Goldberg, Allen↗
NASA NTRS2004

Applying Jlint to Space Exploration Software

Java is a very successful programming language which is also becoming widespread in embedded systems, where software correctness is critical. Jlint is a simple but highly efficient static analyzer that checks a Java program for several common errors, such as null pointer exceptions, and overflow errors. It also includes checks for multi-threading problems, such as deadlocks and data races. The case study described here shows the effectiveness of Jlint in find-false positives in the multi-threading warnings gives an insight into design patterns commonly used in multi-threaded code. The results show that a few analysis techniques are sufficient to avoid almost all false positives. These techniques include investigating all possible callers and a few code idioms. Verifying the correct application of these patterns is still crucial, because their correct usage is not trivial.

Artho, Cyrille↗
NASA NTRS2011

Symbolically Modeling Concurrent MCAPI Executions

Improper use of Inter-Process Communication (IPC) within concurrent systems often creates data races which can lead to bugs that are challenging to discover. Techniques that use Satisfiability Modulo Theories (SMT) problems to symbolically model possible executions of concurrent software have recently been proposed for use in the formal verification of software. In this work we describe a new technique for modeling executions of concurrent software that use a message passing API called MCAPI. Our technique uses an execution trace to create an SMT problem that symbolically models all possible concurrent executions and follows the same sequence of conditional branch outcomes as the provided execution trace. We check if there exists a satisfying assignment to the SMT problem with respect to specific safety properties. If such an assignment exists, it provides the conditions that lead to the violation of the property. We show how our method models behaviors of MCAPI applications that are ignored in previously published techniques.

Fischer, Topher↗
NASA NTRS1936

Further measurements of normal accelerations on racing airplanes

The work of collecting acceleration data for racing airplanes during races, started in January 1934, has been continued by obtaining similar data in the airplanes winning first and second places in the 1935 Thompson Trophy Race. Records were taken in the Howard Racer "Mr. Mulligan" and in the Wittman D-12 Racer. The maximum positive accelerations were generally smaller than those recorded in other airplanes during earlier races; the maximum in the Howard Racer was 2.8 g, and one value of 4.25 g was obtained in the Wittman Racer. Minimum values were as low as -0.55 g in the Howard Racer and 0.3 g in the Wittman Racer.

Scudder, N F↗
NASA NTRS2013

Kennedy Space Center Spaceport Analysis

Until the Shuttle Atlantis' final landing on July 21, 2011, Kennedy Space Center (KSC) served as NASA's main spaceport, which is a launch and landing facility for rockets and spacecraft that are attempting to enter orbit. Many of the facilities at KSC were created to assist the Shuttle Program. One of the most important and used facilities is the Shuttle Landing Facility (SLF), This was the main landing area for the return of the shuttle after her mission in space. · However, the SLF has also been used for a number of other projects including straight-line testing by Gibbs Racing, weather data collection by NOAA, and an airfield for the KSC helicopters. This runway is three miles long with control tower at midfield and a fire department located at the end in care of an emergency. This facility, which was part of the great space race, will continue to be used for historical events as Kennedy begins to commercialize its facilities. KSC continues to be an important spaceport to the government, and it will transform into an important spaceport for the commercial industry as well. During my internship at KSC's Center Planning and Development Directorate, I had the opportunity to be a part of the negotiation team working on the agreement for Space Florida to control the Shuttle Landing Facility. This gave me the opportunity to learn about all the changes that are occurring here at Kennedy Space Center. Through various meetings, I discovered the Master Plan and its focus is to transform the existing facilities that were primarily used for the Shuttle Program, to support government operations and commercial flights in the future. This. idea is also in a new strategic business plan and completion of a space industry market analysis. All of these different documentations were brought to my attention and I. saw how they came together in the discussions of transitioning the SLF to a commercial operator, Space Florida. After attending meetings and partaking in discussions for the SLF Agreement, I formed the idea of a Spaceport Analysis as my over internship project. As previously stated, I had the opportunity to sit in on the market analysis meetings and read through the analysis itself. I suggested the creation of a Strengths Weaknesses Opportunities Threats (SWOT) analysis, which allows an individual to see an overview of the company's strengths and weaknesses alongside any industry opportunities and threats. After discussions with the lead writer of the new strategic business plan and getting approval, I took the action upon myself and created the Kennedy Space Center SWOT Analysis.

Wary, Samantha A.↗
NASA NTRS2010

Occupant Protection at NASA

This slide presentation reviews NASA's efforts to arrive at protection of occupants of the ORION space craft on landing. An Abbreviated Injury Scale (AIS) has been developed, it is an anatomically-based, consensus-derived, global severity scoring system that classifies each injury by body region according to its relative importance on a 6-point ordinal scale. It reviews an Operationmally Relevant Injury Scale (ORIS), a classification methodology, and shows charts that detail the results of applying this ORIS to the injury databases. One chart uses NASCAR injury classification. It discusses providing a context for the level of risk inherent in the Orion landings in terms that people understand and have a sense for. For example is the risk of injury during an Orion landing roughly the same, better or worse than: An aircraft carrier landing, a NASCAR crash, or a helicopter crash, etc? The data for NASCAR and Indy Racing league (IRL) racing crash and injury data was reviewed. The risk from the Air Force, Navy, and Army injury data was also reviewed. Past NASA and the Soyuz programs injury risks are also reviewed. The work is an attempt to formulate a recommendation to the Orion Project for an acceptable level of injury risk associated with Nominal and Off-Nominal landing cases. The presentation also discusses the data mining and use of the data to Validate NASA Operationally-Relevant Injury Scale (NORIS) / Military Operationally-Relevant Injury Scale (MORIS), developing injury risk criteria, the types of data that are required, NASCAR modeling techniques and crash data, and comparison with the Brinkley model. The development of injury risk curves for each biodynamic response parameter is discussed. One of the main outcomes of this work is to establish an accurate Automated Test Dummy (ATD) that can be used to measure human tolerances.

Somers, Jeffrey↗