[Soot-list] Combining -no-bodies-for-excluded and -cg paddle on:bdd

Severin Heiniger severinheiniger at gmail.com
Mon Mar 28 19:27:19 EDT 2011


Hi,

I'm currently doing a whole-program analysis [1] on parts of a rather
extensive set of packages. As expected, only by using
-no-bodies-for-excluded and carefully choosing -x, the analysis terminates
in a reasonable amount of time. However, even for trivial Java programs,
when enabling BDD support in Paddle, Soot soon exits with the following
error message:

This operation requires resolving level HIERARCHY but
> java.nio.channels.spi.SelectorProvider is at resolving level DANGLING
>
[...]
>
at soot.jimple.paddle.BDDHierarchy.processNewType(BDDHierarchy.java:194)
>

This library class is at resolving level DANGLING no matter if BDD support
is used or not. Does anybody know why this and other such classes are not
resolved to the level HIERARCHY or SIGNATURE even though this kind of
information is required by Paddle? Certainly, adding all such classes using
addBasicClass is not advisable.

Besides, when removing -no-bodies-for-excluded, the BuDDy-supported
context-insensitive analysis (of a trivial Java program) runs for a few
minutes with a memory usage of about 700 MB. On my machine [2], it then
terminates with a segfault [3] or (more) gracefully with an out-of-memory
exception.

Thanks a lot in advance for providing any helpful information regarding
these problems!

Kind regards,
Severin

[1] Nightly build of Soot etc. using [...] -w -app -no-bodies-for-excluded
-p paddle on [...]
[2] 32-bit Ubuntu 10.10 with OpenJDK 6
[3] [libjeddbuddy.so+0x26f05]  bdd_makenode+0x75
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20110329/10cac731/attachment.html 


More information about the Soot-list mailing list