[Soot-list] Call graphs and excluding libraries

[John A Toman]

Hi Steven,

The freemarker library actually does put all its classes in the top-level
freemarker.* package so I believe that my -x usage is correct.

As for your first point, I have been including all of the libraries
(including the JDK libraries) because my first attempts to use Soot without
them failed with missing class errors; I inferred that Soot would not
function properly unless I included all classes that could be potentially
referenced by the program being analyzed. If I understand you correctly
there is some combination of flags and classpaths that will instruct Soot
to simply ignore library classes (including the JDK). If this is true, what
is the behavior of, say, the IFDS solver in the presence of these ignored
libraries? If an application class calls into library method foo() that has
been excluded what does Soot do with that call?

With regards to the strange call resolution, that problematic call
statement appears to be in a library class that I wish to exclude anyway so
the problem may become moot if I can figure out the above problem. Although
it may still be a bug :)

Thanks!
John


On Thu, Jun 11, 2015 at 2:04 AM, Steven Arzt <Steven.Arzt at cased.de> wrote:

> Hi John,
>
>
>
> That’s strange, your command-line looks good to me in principle. Your
> exclusion is not correct, you have to provide package or class names which
> would probably be something like com.freemarker.*. Soot does not search for
> substrings here, but for packages. Another option would be not to
> explicitly exclude these classes, but simply not have them on the Soot
> classpath. In that case, they will automatically become phantom classes.
>
>
>
> The other question is whether you really want to prepend the JVM’s
> classpath to your Soot classpath using –pp if you are ok with ignoring
> libraries at some other place. Is there a specific reason for not excluding
> the JDK as well? As recommended above, I would just remove it from the Soot
> classpath.
>
>
>
> The strange call edge you are experiencing doesn’t sound right to me. Can
> you provide a minimal working example that provides the same kind of
> callgraph with similar wrong edges, but has a more manageable size for
> debugging?
>
>
>
> Best regards,
>
>   Steven
>
>
>
> *Von:* soot-list-bounces at CS.McGill.CA [mailto:
> soot-list-bounces at CS.McGill.CA] *Im Auftrag von *John A Toman
> *Gesendet:* Donnerstag, 11. Juni 2015 02:17
> *An:* soot-list at cs.mcgill.ca
> *Betreff:* [Soot-list] Call graphs and excluding libraries
>
>
>
> Hello!
>
> I'm trying to use Soot for an interprocedural analysis but I'm having
> trouble getting a callgraph. I'm analyzing a web application that depends
> on several libraries, each of which have their own dependencies. These
> dependencies aren't interesting to my analysis but without them I can't
> seem to get a reliable call-graph.
>
> I'm invoking Soot as follows:
>
> java -cp ./soot-trunk.jar:./myanalysis -pp -soot-class-path
> /path/to/application/classes:/paths/to/app/library/jars
> -no-bodies-for-excluded -x 'freemarker' -w -p cg.cha enabled:false -p
> cg.spark enabled:true,verbose:true -p wjtp.myanalysis on com.acme.DummyMain
> -allow-phantom-refs
>
> where freemarker is the package name of the library I'm not interested in
> (I exclude the freemarker.jar from the soot class path in the above
> invocation too)[
>
>
>
> With these options Spark builds a callgraph, but the results are strange.
> For instance, the possible types analysis dies because (as far I as can
> tell) it thinks that a call to <java.security.AccessController:
> java.lang.Object doPrivileged(java.security.PrivilegedAction)>
>
> potentially resolves to <org.apache.commons.logging.LogFactory$1:
> java.lang.Object run()>.
>
> Without the -no-bodies-for-excluded option Spark churns for a while until
> it reaches some part of the Freemarker library that relies on Jython.
> However, the Jython jar also has unmet dependencies which cause Spark to
> choke...
>
> In short: how do I configure Soot to ignore missing/uninteresting library
> calls with the least effort possible?
>
> Thanks!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20150611/bf3621d1/attachment.html