Dynamic and static analysis
Connecting state and local government leaders
GCN Insider: When it comes to inspecting a new program for bugs, there are two broad approaches a reviewer can take.
When it comes to inspecting a new program for bugs, there are two broad approaches a reviewer can take. One is static analysis, in which a coder, or a program, dutifully combs through each line of code, watching what it does and looking for ways that it could disrupt things.
The second approach is known as dynamic analysis. This method involves compiling and running the program and watch what each thread that program spawns does. This dynamic approach can be invaluable in pinpointing bugs that can slow or crash a program that are not obvious from code review.
One security review vendor, Coverity, has delved into dynamic analysis with a new program, Coverity Thread Analyzer for Java. You may recognize the name Coverity. The company, with Homeland Security Department funding, reviews opensource programs for errors and posts the results. The new analyzer will watch a program as it executes. It complements Coverity's static analysis program, Prevent.
The program can root out problems that could lie dormant for thousands of runtime hours before crashing the system, said Ben Chelf, chief technical officer for Coverity. It can find race conditions, where two threads compete for the same resource, which can cause unpredictable behavior. It can find potential deadlocks, in which two resources wait for each other to finish, effectively bringing both to a halt.
Of course, Thread Analyzer is not the first product to do dynamic tracing. Sun Microsystems' opensource DTrace, for instance, is widely used by debuggers. DTrace's limitation is that 'it can tell you only what happened to that one execution,' Chelf said. 'We want to see not only what happened but infer what might happen.'
The program does this by adding hooks into the bytecode of the Java program under study. The source code is not required. 'By putting in these hooks, we can watch every time the threads try to communicate, either through acquiring locks, or accessing data,' Chelf said. With this data, the program can then 'compute what might occur in other execution environments.'