Applying Jlint to Space Exploration Software
Summary (2 min read)
1 Introduction
- Therefore an automated tool which can detect faults easily, preferably early in the lifecycle of software, can be very useful to find defects.
- Among similar tools geared towards Java, it is one of the most suitable with respect to ease of use (no annotations required) and free availability (the tool is Open Source) [I]. . . .
13 Outline
- This text is organized as follows: Section 2 describes Jlint and how it was used for this project.
- Sections 3 and 4 show the results of applying Jlint to space exploration program code.
- Design patterns which are common among these two projects are analyzed in Section 5.
- Section 6 summarizes the results and concludes.
2.1 Tool description
- Typical warnings about possible faults issued by Jlint are n u l l pointer dereferences, array bounds overflows, and value overflows.
- The latter may occur if one multiplies two 32 bit integer values without converting them to 64 bit fist Many warnings that Jlint issues are code guidelines:.
I
- Jlint also includes many analyses for multi-threaded programs.
- Some of Jlint's warnings for multi-threaded programs are overly cautious.
- Possible data race warnings for method calls or variable accesses do not necessarily imply a data race.
- The reason for such false positives are both difficulties inherent to static analysis, such as pointer aliasing across method calls, and limitations in Jlint itself, where its algorithms could be refined with known techniques.
2.2 Warning review process
- During the review process, Jlint's warnings were categorized to see whether they refer to the same problem.
- Such situations constitute calls to the same method from different callers, the same variable used in different contexts, or the same design pattern applied throughout the class.
- In a separate count, counting the number of distinct problems rather than individual warnings, all such cases were counted once.
- Furthermore, the time required for this process was recorded.
- Note that the review activity was often interrupted by other activities such as writing this paper.
3.2 Jlint evaluation
- The 30 deadlock warnings all referred to the same two classes.
- There were two sets of warnings, the first set containing ten, the second one 20 warnings.
- The first ten warnings, all of them false positives, showed incomplete loops in the call graph.
- Another lock was used that makes a deadlock possible.
- Therefore these warnings referred to actual faults in the code.
Results:
- While reviewing the multi-threading warnings was time-consuming due to the complex interactions in the code, it was feasible and helped to highlight the critical parts of the source code.
- The effort was justifiable for a project of this complexity.
3.3 Comparison to other projects
- The eleven new bugs found by J h t were a great success, even considering that the seven deadlocks correspond to two classes where other deadlocks have been known to occur.
- Jlint reported different methods than those reported in otiier analyses.
4 DS1
- The second case study consisted of an attitude control system and a fault protection system for the Deep Space 1 @SI) space craft.
- For the DS1 code base, it took 0.17 seconds to check the entire code base on the same PowerPC G4 with a clock frequency of 500 MHz.
4.1 Description of DSI
- DS1 was a technology-testing mission, which was launched October 24 1998, and which ended its primary mission in September 1999.
- DS1 contained and tested twelve new kinds of space-travel technologies, for example, ion propulsion and artificial intelligence for autonomous control.
- The attitudecontrol system monitors and controls the space craft's attitude, that is, its position in 3dimensional space.
- The fault-protection system monitors the operation of the space craft and initiates corrective actions in case errors occur.
- The original C code was re-designed in Java, using best practices in object-oriented design.
4.2 Jlint evaluation
- This study indicates that four design patterns prevail in cases where code is apparently not thread-safe: Synchronization of all callers, use of read-only values, threadlocal copies of data, and the use of thread-safe container classes.
- Some of the data race warnings for the Rover code pointed out cases where it was attempted to use the read-only pattern, but the use was not carried out consistently throughout the project.
- Such a small mistake violates the property that guarantees thread-safety.
6 Conclusions
- An analysis of the false positives showed that in apparently thread-unsafe code, four common design patterns ensure thread-safety in all cases.
- Static analysis tools should therefore be extended with specific algorithms geared towards these patterns to reduce false positives.
- Furthermore, these patterns were not always applied correctly and are still a significant source of programming errors.
- This calls for tools that verify the correct application of these patterns, thereby pointing out even more subtle errors than previously possible.
Did you find this useful? Give us your feedback
Citations
53 citations
Cites methods from "Applying Jlint to Space Exploration..."
...Tools that support both timing and state, and input validation and representation bugs include: ESC [8], a Modula-3 and Java checker that uses a theorem prover (Simplify) to reason about the semantics of language constructs, driven by annotations in the code; Coverity [10, 11], a C, C++ and Java checker based on \may belief" analysis; Jlint [1, 2 ], a checker of Java classles that is based on data ow and abstract interpretation; ......
[...]
...The program initializes two buers: the stack buer buf is initialized to the \AAA...A" string with a trailing C end-of-string character, and the heap buer buf2 is initialized to the input data provided as the third parameter to the program (argv[ 2 ]), after allocating data from the heap of size equal to the second parameter (argv[1])....
[...]
...In the example there are two user inputs: the length of the data (argv[1]) and the string of data (argv[ 2 ])....
[...]
26 citations
Cites background from "Applying Jlint to Space Exploration..."
...Remainder of this paper is organized as follows....
[...]
18 citations
13 citations
Cites methods from "Applying Jlint to Space Exploration..."
...Like FindBugs, JLint [41] applies syntactic bug patterns and dataflow analysis on AUT bytecode, but it is not easy to expand [21]....
[...]
...JLint Like FindBugs, JLint [41] applies syntactic bug patterns and dataflow analysis on AUT bytecode, but it is not easy to expand [21]....
[...]
13 citations
References
481 citations
395 citations
"Applying Jlint to Space Exploration..." refers background or methods in this paper
...Other reasons for false positives were the use of thread-safe container classes in such methods, the use of read-only fields, and per-thread confinement [ 18 ], which always creates a new instance as return value....
[...]
...‐ Copying method parameters restricts data ownership to the called method and the current thread [ 18 ]....
[...]
...‐ The usage of (deep) copies of data returned by a method ensures that the “working copy” used subsequently by the caller remains thread-local [ 18 ]....
[...]
...Reasons for false positives include the use of thread-local copies [ 18 ] or a thread-safe container class....
[...]
289 citations
270 citations
227 citations