TamiFlex 1.1 released

Eric | August 4, 2010

I am happy to announce that today we released version 1.1 of TamiFlex, our tool suite for dealing with reflection and custom class loaders in static analysis. Version 1.1 not only features several minor bug fixes but a completely new component called the Booster. Previous versions of TamiFlex required static analyses that were “TamiFlex-aware”, and at the current time the only such tool is Soot. The Booster makes TamiFlex compatible with virtually every static-analysis tool for Java bytecode: it transforms the original program into a new program version that is enriched with “materialized” versions of the originally reflective method calls, now in the form of standard Java method calls. Because these calls are now materialized in the code, static-analysis tools will discover them instead of unsoundly ignoring the calls.

Comments
Comments Off on TamiFlex 1.1 released
Categories
Research
Tags
Java, Soot, Static Analysis, TamiFlex

Whole-program analysis, but without the JDK (using Soot)

Eric | June 4, 2010

In the past many people have asked how they can configure Soot so that it would analyze a given set of classes, but without analyzing all the internals of the JDK. Of course, such an analysis is generally unsound, but often people don’t really care – they just want to have fast results. I have often found myself in the same situation when testing whole-program analyses that I wrote myself. Every analysis run would normally take minutes to run, which can cause your day to pass by quickly when you are debugging a complicated analysis.

Today I added a new option to Soot: -no-bodies-for-excluded. This option causes Soot to not load any method bodies of classes from the “exclude” packages (see –exclude option), even in whole-program mode, unless the class is explicitly as a “basic class”. -no-bodies-for-excluded implies -allow-phantom-refs, as it uses the phantom-refs mechanism to model classes that are not loaded.

All changes have been committed to SVN. This feature is still experimental, but it appears to work for me – I am now able to run all of Clara‘s tests in seconds each instead of minutes each, just because they now ignore JDK classes.

Comments
Comments Off on Whole-program analysis, but without the JDK (using Soot)
Categories
Research
Tags
Java, Soot, Soot Tutorial

Explanations of common Java exceptions

Eric | May 3, 2010

Today, my colleague Marcel Bruch pointed me to this Explanation of common Java exceptions. I found it very useful. Maybe you like it too ;-)

Comments
2 Comments »
Categories
Misc
Tags
Exceptions, Java

Where did Java 5 go?

Eric | September 3, 2009

Screen shot 2009-09-03 at 13.27.17 Today, when I installed MacOS X Leopard, I was surprised to see that the update had remove Java 5 from the disk! The “1.5” folder now is just a symbolic link to the 1.6 JDK! Where is the sense in that? I guess I am not the only developer who just needs a 1.5 JDK from time to time. I don’t care about the old VM but I do care about the old class libraries. When using Java 6 libraries to develop Java 5 compatible code it can easily happen that one uses APIs that were not available in 1.5. Luckily I had time machine set up, so it was easy to get back the “real JDK”. No wonder they save so much disk space in Snow Leopard …

Comments
Comments Off on Where did Java 5 go?
Categories
Misc, Research
Tags
Apple, Java, Mac

New publication: Object representatives: a uniform abstraction for pointer information

Eric | August 5, 2008

And yes, we have yet another publication. This one has been accepted at BCS 2008. The conference promises to be an interesting event, as the British Computer Society managed to line up seven Turing Award winners to give keynote talks. Laurie Hendren, my supervisor, will be an invited speaker. Very unfortunately, I don’t think that I will be able to attend. So in case you go there, good for you and please try to speak with Patrick Lam instead, who will presenting the paper.

Anyway, so what are Object Representatives all about? Object Representatives are a sometimes very useful, uniform static abstraction of runtime objects that we came up with when evaluating tracematches ahead-of-time. At compile time, an Object Representative (OR) is just a plain old Java object that implements the interface below.

Read the rest of this entry »

Comments
Comments Off on New publication: Object representatives: a uniform abstraction for pointer information
Categories
Research
Tags
Java, Object representatives, Soot, tracematches

Data races in the JDK!

Eric | June 14, 2008

At the moment I am doing some more work on evaluating tracematches ahead-of-time. One tracematch patten that we use in our benchmarks we called ASyncIter, a simplified version of which looks as follows:

tracematch(Collection c) {
	sym sync after returning:
		call(* Collections.synchr*(..)) && args(c);
	sym iter before:
		call(* Collection.iterator()) && target(c);

	sync iter {
		if(!Thread.holdsLock(c))
			error(``Have to synchronize iterator at ''+thisJoinPoint);
        }
}

This tracematch reports an error if you create a synchronized collection and then iterate over this collection without holding a lock on the collection object. According to the JDK javadoc this is forbidden as it can lead to a race condition. One has to use synchronized collections as follows:

Read the rest of this entry »

False positives and negatives of the Racer algorithm

Eric | June 11, 2008

Today I gave a presentation about Racer in our lab seminar and people asked me some really interesting questions. I thought the answers might interest other people too so I would post them here…

Can Racer produce false positives?

Yes, Racer can produce false positives but out of our 70 reported races only two were false positives. There are two primary reasons for false positives. First reason (quoting from the paper):

Read the rest of this entry »

Comments
Comments Off on False positives and negatives of the Racer algorithm
Categories
Research
Tags
Bug finding, Java, Race detection

varargs is patented!?

Eric | May 23, 2008

imageVarargs is a feature that allows you to pass a variable-length list of arguments to a method, e.g. in Java 5. The implementation in Java boxes these arguments automatically into an array, which makes the implementation backwards compatible. As I just found out, this technique has actually been patented by HP. Interesting… I wonder whether Sun actually licensed that technology for Java somehow.

Comments
Comments Off on varargs is patented!?
Categories
Research
Tags
Java, Patent

Racer: Effective Race Detection Using AspectJ

Eric | May 7, 2008

image

I am happy to announce the availability of my latest publication (joint work with Klaus Havelund, to appear at ISSTA 2008). This time it’s about how to detect data races in multi-threaded Java programs using three novel pointcuts that we implemented as a language extension to AspectJ, and using a novel algorithm called Racer that makes use of these pointcuts. We applied our implementation to the NASA K9 Rover Excecutive and found 70 data races, only one of which was known to NASA developers, although extensive studies had been performed on the code, using all sorts of error detection tools, at a time where 68 of these races were already present!

Download the paper here, our extended Technical Report here, or continue reading here.

Comments
Comments Off on Racer: Effective Race Detection Using AspectJ
Categories
Research
Tags
AspectJ, Bug finding, Java, NASA, Race detection, Racer, Rover, Semantic pointcuts

Crashing javac

Eric | April 18, 2008

As I am preparing to hold COMP 520 in Fall, I just read through Michael Schwarzbach’s excellent new version of this lecture. He has one set of exercises on name resolution containing this funny example:

public class java {
    public class lang {
        public class Object {}
    }
}

Give this code to javac and it will bail on you:

mucuna /tmp $ javac java.java
An exception has occurred in the compiler (1.6.0_05). Please file a bug at the
Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking
the Bug Parade for duplicates. Include your program and the following diagnostic
in your report.  Thank you.
java.lang.NullPointerException
at com.sun.tools.javac.comp.Flow.visitIdent(Flow.java:1214)
at com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:1547)

Funny, eh?