[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