[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