[Soot-list] instrumenting with soot class by class
David Vollmar
kavika at the-dave.com
Tue Apr 22 11:43:56 EDT 2008
All,
I am trying to solve my problem now in a different manner: I can
determine which classes I want to instrument, so I just will use soot
to instrument classes one at a time in a very targeted fashion. The
problem that I am running into is one of performance: Starting a new
JVM for each class that I want to instrument becomes very expensive,
so I would like to reuse the same JVM for instrumenting different
classes. This approach works fine for the first class I try to
instrument, but on the next pass, I am getting this stack trace:
[java] Exception in thread "main" java.lang.NullPointerException
[java] at
soot.SootMethod.getBodyFromMethodSource(SootMethod.java:81)
[java] at soot.SootMethod.retrieveActiveBody(SootMethod.java:320)
[java] at soot.PackManager.retrieveAllBodies(PackManager.java:
863)
[java] at soot.PackManager.runPacks(PackManager.java:323)
[java] at soot.Main.run(Main.java:203)
I am guessing I need to somehow clear out the static variables in
Soot, but I don't know how. Could someone please point me in the right
direction?
Thanks!
=
=
=
=
=
=
=
=
=
=
========================================================================
My instrumentation class looks something like this:
public class MyInstrumenter extends BodyTransformer {
protected static MyInstrumenter instance = new MyInstrumenter();
protected MyInstrumenter() {
}
public static MyInstrumenter v() {
return instance;
}
protected void internalTransform(Body body, String pn, Map map) {
.....
}
public void setup() {
Scene.v().loadClassAndSupport("com.foo.bar.Call");
PackManager.v().getPack("jtp").add(
new Transform("jtp.instrumenter", MyInstrumenter.v()));
}
public void instrumentClass(String aClassName) {
String [] args = new String [] {aClassName};
soot.Main.main(args);
}
}
=
=
========================================================================
On Apr 18, 2008, at 1:44 PM, Richard L. Halpert wrote:
> I recall someone asking about this type of use on the Soot list in
> the past. It might be useful to have a mechanism inside Soot to
> decide if a class should be written to file or not... for example if
> the decision on whether or not to transform a class needs to be
> determined by analyzing the class. Perhaps...
>
> -Rich
>
> On Fri, Apr 18, 2008 at 12:30 PM, Eric Bodden <eric.bodden at mail.mcgill.ca
> > wrote:
> > I have contemplated that approach, yet I would find it much more
> elegant if
> > Soot would offer a feature that would take care of this particular
> issue.
> > I am guessing that more people would be interested in this
> particular
> > performance improvement.
>
> I am not sure. My guess is that most people use Soot for whole program
> analysis and not on a file-by-file basis. But nevertheless there may
> be some people who have use cases similar to yours.
>
> > So I am contemplating digging into the internals of Soot in order
> to see
> > whether I can implement this feature.
> > What do you think?
>
> Sure, give it a try and let us know how it works. Depending on
> somebody's Ant skills it's probably not harder than writing an Ant
> script ;-)
>
> Eric
>
> --
> Eric Bodden
> Sable Research Group
> McGill University, Montréal, Canada
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20080422/7894b04a/attachment.htm
More information about the Soot-list
mailing list