#61 Incorrect ProgramCounter values for methods calls in rt.jar

[Anonymous]

Hello,
I did a ZeroCFA analysis on a program, and generated the CallGraph, and
I remarked that ProgramCounter values are incorrect for some java
runtime classes (using wala method CallGraph.getPossibleSites(GCNode
src, GCNode target)).
For example:
src method is: java.lang.Object java.util.HashMap.get(java.lang.Object)
one of the targets methods is: bool
java.lang.Integer.equals(java.lang.Object)
The program counter value given by the "getPossibleSites" wala method is
the index 73.
But analysing the bytecode, of the HashMap.class with "javap -c",
indicates that the index 73 corresponds to a "astore 3" in the method
java.lang.Object java.util.HashMap.get(java.lang.Object). (Index 58
seems to be the good index with a virtual call to //Method
java/lang/Object.equals:(Ljava/lang/Object;)Z)
The runtime (rt.jar) I used to get the HashMap.class is the same that I
configured for the java_runtime_dir of the "wala.properties" file. In
some cases the program counter value given is not a valid start of
opcode in bytecode.

This appends for these classes (in some methods) with the analyzed program
:
-java.util.HashMap
-java.lang.StringValue

Otherwise program counter values seems to be correct and I used the
jdk1.6.0_16 for the analysis.

I attached an archive containing an example program that allows to reproduce the problem:
TestProgramCounterProblem.jar : The program to analyze
TestProgramCounterProblem.txt : The descriptive of jar files to use for analysis (parameter for CallGraphTestUtil.makeJ2SEAnalysisScope)
dumpCGmethod.java : a modified version of the dumpCG to print readable information with Program Counter value
interesting_results_StringValue.txt: One of the problems of not corresponding ProgramCounter values that i found with jdk1.6.0_16 for this test program
interesting_results_HashMap_put.txt: One of the problems of not corresponding ProgramCounter values that i found with jdk1.6.0_16 for this test program
TestProgramCounterProblem.java : The java source file of analyzed program

To do the analysis:
here are the principal steps of my analysis :

AnalysisScope scope = CallGraphTestUtil.makeJ2SEAnalysisScope(txtJars, CallGraphTestUtil.REGRESSION_EXCLUSIONS);
ClassHierarchy cha = ClassHierarchy.make(scope);
Iterable<Entrypoint> entrypoints = com.ibm.wala.ipa.callgraph.impl.Util.makeMainEntrypoints(scope, cha);
AnalysisOptions options = new AnalysisOptions(scope, entrypoints);
CallGraphBuilder ZeroCFAbuilder = Util.makeZeroCFABuilder(options, new AnalysisCache(), cha, scope);
CallGraph cg = ZeroCFAbuilder.makeCallGraph(options, null);
dumpCG(cg);

Vincent Monfort

PS: Doing this test program I remarked that there is a call to a method of type java.ClassOfTheProblem.access$XXX in the CG that precede (in the order of index in bytecode) the problem of ProgramCounter values. Maybe it could be linked ? And please, do you know what is this call to methods .access$XXX that does not exist in the bytecode ?

[Nobody/Anonymous]

A test program to analyze with ZeroCFA that shows problems of incorrect ProgramCounter values (see message for complete desc.)

[Stephen Fink]

The access$XXX do appear in the bytecode. These are methods generated by javac to allow inner classes to bypass access control and access private or protected members of an enclosing class.

[Stephen Fink]

Here's a test case I'm debugging .. I put this in CallGraphTest and set the classpath to pick up the files appropriately:

@Test
public void testBug() throws ClassHierarchyException, IllegalArgumentException, CancelException, IOException {

String scopeFile = "TestProgramCounterProblem.txt";

AnalysisScope scope = CallGraphTestUtil.makeJ2SEAnalysisScope(scopeFile, CallGraphTestUtil.REGRESSION_EXCLUSIONS);
ClassHierarchy cha = ClassHierarchy.make(scope);
Iterable<Entrypoint> entrypoints = com.ibm.wala.ipa.callgraph.impl.Util.makeMainEntrypoints(scope, cha);
AnalysisOptions options = new AnalysisOptions(scope, entrypoints);
CallGraphBuilder ZeroCFAbuilder = Util.makeZeroCFABuilder(options, new AnalysisCache(), cha, scope);
CallGraph cg = ZeroCFAbuilder.makeCallGraph(options, null);
System.err.println(cg);
}

[Stephen Fink]

I set the following property in wala.properties and ran the test case below. The following is my installation of the Sun 1.6.16 JDK for Win32

java_runtime_dir = C:/Java/jdk6_16

The output shows a call graph that does not include the HashMap.get() method. So, I am so far unable to reproduce the problem.

I'll attach the output.

[Stephen Fink]

output from test case as described