[prev in list] [next in list] [prev in thread] [next in thread] 

List:       soot-list
Subject:    Re: [Soot-list] SootClass.getMethodByName
From:       "Steven Arzt" <Steven.Arzt () cased ! de>
Date:       2016-01-12 14:59:12
Message-ID: 006d01d14d49$cc95dd60$65c19820$ () cased ! de
[Download RAW message or body]

Hi Eugen,

This behavior is expected given how the Soot resolver works. You only instruct it to \
load one specific class and nothing else. Consequently, nothing else is resolved. If \
you try to access a method inside a non-resolved class, it simply isn't there. The \
call to getMethod() triggers to resolver to find the target for that invocation \
expression, thereby loading the missing method. Afterwards, it's there and can be \
accessed.

My suggestion is to not use loadClassAndSupport or any of those methods. These are \
low-level methods, so unless you really know how the Soot resolver works internally, \
the results you will get can be quite surprising. The better method is to create a \
BodyTransformer, register it with the PackManager and then call Soot's normal main() \
method which will take care of all the required loading and initialization. There is \
a quite good introduction into the basic concepts of Soot in Eric's blog: \
http://www.bodden.de/2008/11/26/soot-packs/

Best regards,
  Steven

-----Ursprüngliche Nachricht-----
Von: Eugen Zalinescu [mailto:eugen.zalinescu@gmail.com] 
Gesendet: Dienstag, 12. Januar 2016 13:54
An: Steven Arzt
Cc: soot-list@cs.mcgill.ca
Betreff: Re: [Soot-list] SootClass.getMethodByName

Hi Steven,

Here are more details. Now I've also localized the call where the change in behavior \
occurs.

I'm doing an analysis (using ForwardFlowAnalysis) of a Java class, and the 'main' \
method looks something like this:

SootClass c = Scene.v().loadClassAndSupport("securibench.micro.basic.Basic30");
c.setApplicationClass();
SootMethod m = c.getMethodByName("doGet") Body b = m.retrieveActiveBody(); \
ExceptionalUnitGraph g = new ExceptionalUnitGraph(b); // build a ForwardFlowAnalysis \
object from g

Now, in the flowThrough method, for the unit d that is 'r3 = interfaceinvoke \
r1.<javax.servlet.http.HttpServletRequest: java.lang.String \
getParameter(java.lang.String)>("name");' the code looks like this:

Main.testExists(); // here method not found SootMethod m = \
((InvokeExpr)d).getMethod(); Main.testExists(); // here method found

where testExists in Main is:
static void testExists() {
        try {
            SootClass c =
Scene.v().getSootClass("javax.servlet.http.HttpServletRequest");
            c.getMethodByName("getParameter");
            System.out.println("IT WORKS!!!");
        } catch (RuntimeException e) {
            System.out.println("It does NOT work.");
        }
    }

So it seems that the call to InvokeExpr.getMethod() makes the difference. My main \
question is why is this, and my second question would be how to make Soot find the \
'getParameter' method before starting the analysis.

Thanks,
Eugen







On Tue, Jan 12, 2016 at 12:05 PM, Steven Arzt <Steven.Arzt@cased.de> wrote:
> Hi Eugen,
> 
> Without further details, it's hard to estimate what's happening there. 
> Maybe your first calls happens at a point in time when the class has 
> not been loaded yet. If you are using multiple threads in your code, 
> you might be trying to access  the method while Soot's resolver is 
> still loading the bodies.
> 
> Best regards,
> Steven
> 
> -----Ursprüngliche Nachricht-----
> Von: soot-list-bounces@CS.McGill.CA 
> [mailto:soot-list-bounces@CS.McGill.CA]
> Im Auftrag von Eugen Zalinescu
> Gesendet: Montag, 11. Januar 2016 16:42
> An: soot-list@CS.McGill.CA
> Betreff: [Soot-list] SootClass.getMethodByName
> 
> Hello,
> 
> I get the following behavior. At some point in the program calling the 
> method SootClass.getMethodByName raises an exception, concretely:
> Exception in thread "main" java.lang.RuntimeException: No method
> getParameter in class   javax.servlet.http.HttpServletRequest
> while calling the same method on the same SootClass object later 
> during the analysis, with the same arguments returns the looked for method.
> 
> This seems strange to me, but maybe someone has an explanation for it?
> 
> Thanks,
> Eugen
> _______________________________________________
> Soot-list mailing list
> Soot-list@CS.McGill.CA
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list
> 

_______________________________________________
Soot-list mailing list
Soot-list@CS.McGill.CA
https://mailman.CS.McGill.CA/mailman/listinfo/soot-list


[prev in list] [next in list] [prev in thread] [next in thread]