[Soot-list] Use SOOT to analyse Java library.

[christian.grosse at comhem.se]

Hello!

I tried the program below and debugged it with SOOT in Eclipse.

public class Test {
    public static void main(String[] args) {
        String newargs[] = {
        "-allow-phantom-refs",
        "-include-all",
        "-d", "c:\\Temp",
        "-process-dir","C:\\Program Files 
(x86)\\Java\\jre1.8.0_31\\lib\\rt.jar",
        "-cp","C:\\Program Files 
(x86)\\Java\\jre1.8.0_31\\lib\\jce.jar","C:\\Program Files 
(x86)\\Java\\jre1.8.0_31\\lib\\jsse.jar"};

        soot.Main.main(newargs);
    }
}

In the constructor for BafBody, the program will try to translate the 
statement “if $r3 == null goto label1;” for method setValue() in class 
java.time.format.DateTimeFormatterBuilder$ReducedPrinterParser and will 
generate an exception: java.lang.RuntimeException: Unit graph contains jump 
to non-existing target. This exception is generated from code inside the 
toString() method for the class Body (see stack trace below). I think that 
the Eclipse debugger calls that function to provide object detail in the 
Debugger view. So the toString() method has some unwanted side effects, I 
think. The exception is caught and printed in toString(), and after that we 
get the error java.lang.RuntimeException: invalid fromType 
java.time.format.DateTimeParseContext, that we discussed before.

java.lang.RuntimeException: Unit graph contains jump to non-existing target
\u0009at 
soot.toolkits.graph.UnitGraph.buildUnexceptionalEdges(UnitGraph.java:128)
\u0009at soot.toolkits.graph.BriefUnitGraph.<init>(BriefUnitGraph.java:62)
\u0009at soot.Printer.printTo(Printer.java:288)
\u0009at soot.Body.toString(Body.java:585)
\u0009at soot.baf.BafBody.<init>(BafBody.java:95)
\u0009at soot.baf.Baf.newBody(Baf.java:560)
\u0009at soot.PackManager.convertJimpleBodyToBaf(PackManager.java:995)
\u0009at soot.PackManager.runBodyPacks(PackManager.java:947)
\u0009at soot.PackManager.runBodyPacks(PackManager.java:608)
\u0009at soot.PackManager.runBodyPacks(PackManager.java:507)
\u0009at soot.PackManager.runPacksNormally(PackManager.java:484)
\u0009at soot.PackManager.runPacks(PackManager.java:391)
\u0009at soot.Main.run(Main.java:243)
\u0009at soot.Main.main(Main.java:152)
\u0009at Test.main(Test.java:21)



public BafBody(Body body, Map<String,String> options) {
.
.
.
    // Convert all jimple instructions
    {
        for (Unit u : jimpleBody.getUnits()) {
            Stmt s = (Stmt) u;
            List<Unit> conversionList = new ArrayList<Unit>();

            context.setCurrentUnit(s);
            ((ConvertToBaf) s).convertToBaf(context, conversionList);

            stmtToFirstInstruction.put(s, conversionList.get(0));
            getUnits().addAll(conversionList);
        }
     }
.
.
.
}

-----Original Message----- 
From: christian.grosse at comhem.se
Sent: Saturday, April 11, 2015 4:14 PM
To: Bodden, Eric ; SOOT mailing list
Subject: Re: [Soot-list] Use SOOT to analyse Java library.

I will download and setup the SOOT source code in Eclipse and se if I can
find the problem.

/Christian G

-----Original Message----- 
From: Bodden, Eric
Sent: Saturday, April 11, 2015 9:25 AM
To: christian.grosse at comhem.se
Cc: Soot list
Subject: Re: [Soot-list] Use SOOT to analyse Java library.

Hi Christian.

> I added the -allow-phantom-refs and got the same runtime exception as you
> did. I also got some Jasmin warnings.
>
> Is this a problem in SOOT?

Yes it’s a bug that should be fixed.

> If I try to use the same class (DateTimeParseContext) in a different
> application with main and all the trimmings, would I get the same Runtime
> exception?

Yes. The options I chose cause Soot to process all classes independently of
one another. So one can easily reproduce that particular bug by just passing
that single class to Soot.

> Will it make any difference if I used Java source (from OpenJDK) or would
> it produce the same problem?

That might go around this particular problem or might not. It depends on
where the bug arises. Having said that, Soot’s source-code frontend is known
to be a lot less stable than the bytecode one, so you would probably not be
better off trying that.

You are most welcome in helping us fix this bug. A good start would be to
product Jimple for the offending class (using the option -f J) and see if
there’s any suspicious cast in there.

Cheers,
Eric

_______________________________________________
Soot-list mailing list
Soot-list at CS.McGill.CA
https://mailman.CS.McGill.CA/mailman/listinfo/soot-list