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

Wed May 6 20:09:20 EDT 2015

Hello.

I have continued to look into the problem and what I have found is this:

Inside the setValue() method in the class DateTimeParseContext,  the 
instruction i7 = (int) r1 results in a BPrimitiveCastInst   (RefType ---> 
int) object, and then an exception is thrown inside the toString() method 
because there is no case for a RefType as a fromtype.

Best regards ChristianG.

-----Original Message----- 
From: christian.grosse at comhem.se
Sent: Thursday, April 16, 2015 12:08 PM
To: SOOT mailing list
Subject: Re: [Soot-list] Use SOOT to analyse Java library.

Ok, So I will not post any bug reports on github.

I will continue to look at the first problem: java.lang.RuntimeException:
invalid fromType java.time.format.DateTimeParseContext

If I understod prof. Bodden that problem might be due to a faulty cast
expression generated by SOOT (boot in Jimple and Baf?). If you (or any on
else) have any tips on how to find the problem I would gladly accept them
:-)

Best regards,
Christian G.

-----Original Message----- 
From: Steven Arzt
Sent: Monday, April 13, 2015 12:57 PM
To: christian.grosse at comhem.se ; 'SOOT mailing list'
Subject: AW: [Soot-list] Use SOOT to analyse Java library.

Hi Christian,

toString() is not necessarily safe for bodies which are not fully
constructed yet. Assume that we generate a piece of code that looks like
this (pseudocode):

goto l1;
foo();
l1 : bar();

If the line "goto l1!" has already been added, but the line "l1 : bar()" not
yet, toString() will produce the problem you observe as the code is invalid
at that point in time. If we however let our construction algorithm move on
finish the body, the label will be there and the body will be valid.
Respectively, toString() will work just fine.

In short, toString() not being able to produce a good result does not
automatically indicate a bug, it might just be due to intermediate bodies
which are not yet complete.

Best regards,
  Steven

-----Ursprüngliche Nachricht-----
Von: soot-list-bounces at CS.McGill.CA [mailto:soot-list-bounces at CS.McGill.CA]
Im Auftrag von christian.grosse at comhem.se
Gesendet: Montag, 13. April 2015 07:05
An: SOOT mailing list
Betreff: Re: [Soot-list] Use SOOT to analyse Java library.

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

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

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