[Soot-list] Unwanted Transformation? Analyzing Library Code?

Arzt, Steven steven.arzt at sit.fraunhofer.de
Mon Mar 26 04:16:26 EDT 2018


Hi Ali,

Soot cannot know the type of the variable, because Java bytecode does not contain types for local variables. Consequently, the type inference algorithm deduces a NULL_TYPE, which essentially means “all we know is that this is an object that is always null”. The callgraph algorithm cannot really do anything useful with a NULL_TYPE, and consequently, we transform it into an explicit exception.

Best regards,
  Steven

From: Soot-list <soot-list-bounces at cs.mcgill.ca> On Behalf Of Ali Ghanbari
Sent: Sunday, March 25, 2018 5:05 AM
To: soot-list at cs.mcgill.ca
Subject: [Soot-list] Unwanted Transformation? Analyzing Library Code?

Hi,
I want to analyze a program which does not have single entry point (i.e. it is a library). The code base, instead, does have a set of test cases.
I built a program using ASM to construct a "mock" main function from those test cases. My program produced statements like the following:

org.apache.commons.math4.exception.NumberIsTooSmallExceptionTest obj0 = null;
obj0.testAccessors();
I thought that as long as the type of obj0 is known, Soot won't have any problem for doing CHA (and doing the rest of whole-program analyses). Unfortunately, I noticed that Soot does some unwanted optimization! I found the following in the .jimple file produced by Soot for my mock main (all other calls to client code were removed!):

r8 = new java.lang.NullPointerException;
specialinvoke r8.<java.lang.NullPointerException: void <init>(java.lang.String)>("This statement would have triggered an Exception: virtualinvoke obj0.<org.apache.commons.math4.exception.NumberIsTooSmallExceptionTest: void testAccessors()>()");
throw r8;
It is very intelligent that Soot can detect that, but (for now) I don't want such transformations!
I would appreciate if you answer the my questions:

1. Is that possible to instruct Soot to analyze the library based on the test cases? I mean without the need for any mock main method to be constructed?

2. Does anyone know how can I avoid this unwanted transformation? Who does that transformation Java compiler or Soot?

Thank you so much
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20180326/41b85eda/attachment.html>


More information about the Soot-list mailing list