Repository: soot-oss/soot

Issue #787: Bytecode offsets and stack offsets in Soot
Created: 2017-10-04T15:53:13Z
Hello,
We are interested in trying to instrument the Java Symbolic Pathfinder model checker in order to support static symbolic execution of code regions (Veritesting).  To be able to do this, we need to identify regions of code that can be statically executed and to translate the static regions.  We were hoping to use Soot to do this; Shimple is an SSA form that is straightforward to translate into static symbolic execution regions.
However in order to do so, we need to be able to precisely map bytecode addresses for instructions corresponding to locations in Shimple, as well as stack offsets and object field references to identifiers in Shimple.  The instruction locations will be used to "trap" the SPF execution to start static symbolic execution.  At these trap points, we need to be able to transfer information in and out of the stack locations and field references that are used by the static code region.
Is it possible to use "as-is" or modify Soot in order to provide this information?  We are interested either in the information from the original code, or, if it is easier, rewritten bytecode from the Soot Shimple form.  In previous versions of Soot, we could grab the bytecode instructions, but it looks like the current version using the ASM front end no longer has support for this.
Once again, the things we need specifically are:

the java bytecode offsets corresponding to Shimple branching statements
the stack offsets for local variables referenced in Shimple
the field numbers associated with field references in Shimple.

Thank you very much for your time!

Duplicate issue #764: Bytecodeoffset with included system libraries
Created: 2017-08-10T15:33:57Z
I am trying to run a basic taint analysis using Flowdroid and I want to get the bytecodeoffsets of the files that I analyze. I have seen that others have used set_coffi(true) for this. This is my Soot configuration:
@Override
public void setSootOptions(Options options) {
    // explicitly include packages for shorter runtime:
    List<String> includeList = new LinkedList<>();
    includeList.add("java.lang.*");
    includeList.add("java.util.*");
    includeList.add("java.io.*");

    Options.v().set_no_bodies_for_excluded(true);
    Options.v().set_allow_phantom_refs(true);

    options.set_include(includeList);

    options.set_output_format(Options.output_format_none);
    Options.v().setPhaseOption("jb", "use-original-names:true");
    Options.v().set_keep_line_number(true);
    Options.v().set_keep_offset(true);
    Options.v().set_coffi(true);
}

When I run the analysis, the call graph construction breaks with the following error:
java.lang.ClassCastException: soot.coffi.CONSTANT_InterfaceMethodref_info cannot be cast to soot.coffi.CONSTANT_Methodref_info
at soot.coffi.CFG.jimpleReturnTypeOfMethodRef(CFG.java:2497)
at soot.coffi.CFG.processFlow(CFG.java:2356)
at soot.coffi.CFG.jimplify(CFG.java:1161)
at soot.coffi.CFG.jimplify(CFG.java:967)
at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:98)
at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:116)
at soot.SootMethod.retrieveActiveBody(SootMethod.java:355)
at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processNewMethod(OnFlyCallGraphBuilder.java:701)
at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processReachables(OnFlyCallGraphBuilder.java:238)
at soot.jimple.toolkits.callgraph.CallGraphBuilder.build(CallGraphBuilder.java:104)
at soot.jimple.toolkits.callgraph.CHATransformer.internalTransform(CHATransformer.java:46)
at soot.SceneTransformer.transform(SceneTransformer.java:39)
at soot.Transform.apply(Transform.java:90)
at soot.RadioScenePack.internalApply(RadioScenePack.java:57)
at soot.jimple.toolkits.callgraph.CallGraphPack.internalApply(CallGraphPack.java:49)
at soot.Pack.apply(Pack.java:118)
at soot.jimple.infoflow.AbstractInfoflow.constructCallgraph(AbstractInfoflow.java:360)
at soot.jimple.infoflow.Infoflow.runAnalysis(Infoflow.java:265)
at soot.jimple.infoflow.Infoflow.computeInfoflow(Infoflow.java:212)
at soot.jimple.infoflow.AbstractInfoflow.computeInfoflow(AbstractInfoflow.java:146)
at edu.cmu.cs.mvelezce.taint.AnalysisTest.basic1Test(AnalysisTest.java:168)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)

Through trial and error, I have discovered that the problem is with adding the java libraries to the analysis. My guess is that soot wants to calculate the bytecodeoffsets of those libraries (which I am not interested). Am I right with my guess? If so, how could I fix this problem? If not, what is the correct way to include java system libraries and get the bytecode offsets of my code and not those libraries?

Closing comment (2017-10-12T23:55:48Z): This is related to #787