[Soot-list] Can't find java.lang.Error

[Marc Hull (Imperial College)]

John Jorgensen wrote:
>>>>>> "mfh02" == Marc Hull (Imperial College) <mfh02 at doc.ic.ac.uk> writes:
>>>>>>             
>
>     mfh02> I've got some code which examines the concrete methods
>     mfh02> of a class and all superclasses, but it always throws
>     mfh02> a NullPointerException when retrieving the active body
>     mfh02> of Object.wait(long, int). This can be recreated
>     mfh02> using:
>
>
>     mfh02> Is this a bug or am I missing some initialisation step which 
>     mfh02> will load the class automatically?
>
> I'm not certain exactly what's going on in your original code,
> but in the short example you've provided to reproduce the error,
> the problem is indeed the absence of initialisation to load some
> classes that Soot needs in order to analyze any code.
>   
> Using information on the two wiki pages, I was able to get your
> example to work by changing it to:
>
>   public static void main(String[] args) {
>     Scene.v().addBasicClass("java.lang.Object", SootClass.BODIES);
>     Scene.v().loadNecessaryClasses();
>     SootClass sClass =
>       Scene.v().getSootClass("java.lang.Object");
>     for (Object o : sClass.getMethods()) {
>       SootMethod method = (SootMethod)o;
>       if (method.isConcrete()) {
>       System.out.println(method.getSignature());
>       Body b = method.retrieveActiveBody();   // fails here
>       }
>     }
>   }
>
> Depending on what you're doing, it might be easier to write your
> code as a new transformation, adding that to some soot "pack",
> and then having your application's main() method call
> soot.Main.main().  The implementation of soot.tools.CFGViewer
> provides a fairly simple application of that technique to add a
> BodyTransformer that will get called for each method
> processed. I'm not sure if it is possible to add a new
> SceneTransformer without modifying soot.PackManager, though
Hi John,
Thanks very much for the help - I added that call and now everything 
works fine! I have noticed that the Soot site seems to encourage 
building new transformations into the framework rather than using it as 
a library; I've considered altering my application for this, but my 
usage may be more suited to the library approach. My application 
observes running user code until particular method calls occur, at which 
point it uses Soot to analyse the classes involved in the call, modifies 
some of their methods and then applies the changes using hot swapping. 
Because of this, the classes to be altered aren't known in advance, so 
soot.Main.main() would have to be invoked each time one of these method 
calls occurs, which might add the overhead of initialisation every time 
I call it?

Best wishes,
Marc