[Soot-list] NullPointerException in soot.SootMethod.getBodyFromMethodSource
Phil Pratt-Szeliga
pcpratts at syr.edu
Wed Jul 4 21:46:41 EDT 2012
Hi Marc-Andre,
There has been a lot of traffic with problems in thee past few days so
forgive me if you already did this. Can you post a full test case that I
can run and produce the problem (I will run it on a machine with 20g of
ram). I will see if I can fix anything.
Phil Pratt-Szeliga
Syracuse University
On Jul 4, 2012 9:42 PM, "Marc-Andre Laverdiere-Papineau" <
marc-andre.laverdiere-papineau at polymtl.ca> wrote:
> Hello,
>
> After increasing the memory limit, I end up with this weird exception:
>
> Exception in thread "main"
> soot.AbstractSootFieldRef$FieldResolutionFailedException: Class
> java.security.spec.PSSParameterSpec doesn't have field DEFAULT :
> java.security.spec.PSSParameterSpec; failed to resolve in superclasses
> and interfacesLooking in java.security.spec.PSSParameterSpec which has
> fields [<java.security.spec.PSSParameterSpec: int saltLen>]
> Looking in java.security.spec.AlgorithmParameterSpec which has fields []
> Looking in java.lang.Object which has fields []
>
> at soot.AbstractSootFieldRef.resolve(AbstractSootFieldRef.java:116)
> at soot.AbstractSootFieldRef.resolve(AbstractSootFieldRef.java:75)
> at soot.jimple.StaticFieldRef.getField(StaticFieldRef.java:75)
> at
>
> soot.jimple.toolkits.typing.fast.AugEvalFunction.eval_(AugEvalFunction.java:195)
> at
>
> soot.jimple.toolkits.typing.fast.AugEvalFunction.eval(AugEvalFunction.java:41)
> at
>
> soot.jimple.toolkits.typing.fast.TypeResolver.applyAssignmentConstraints(TypeResolver.java:406)
> at
>
> soot.jimple.toolkits.typing.fast.TypeResolver.inferTypes(TypeResolver.java:113)
> at
>
> soot.jimple.toolkits.typing.TypeAssigner.internalTransform(TypeAssigner.java:101)
> at soot.BodyTransformer.transform(BodyTransformer.java:51)
> at soot.Transform.apply(Transform.java:104)
> at soot.JimpleBodyPack.applyPhaseOptions(JimpleBodyPack.java:66)
> at soot.JimpleBodyPack.internalApply(JimpleBodyPack.java:89)
> at soot.Pack.apply(Pack.java:124)
> at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:117)
> at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:89)
> at soot.SootMethod.retrieveActiveBody(SootMethod.java:322)
> at soot.PackManager.retrieveAllBodies(PackManager.java:1023)
> at soot.PackManager.runPacksNormally(PackManager.java:370)
> at soot.PackManager.runPacks(PackManager.java:334)
> at soot.Main.run(Main.java:198)
> at soot.Main.main(Main.java:141)
> at ca.polymtl.gigl.casi.darwini.SootMain.main(SootMain.java:165)
>
>
> On 07/04/2012 05:10 PM, Marc-Andre Laverdiere-Papineau wrote:
> > Please ignore that last email.
> >
> > I somehow had still in mind Patrick's suggestion of exiting the VM.
> >
> > I've implemented what Eric suggested, and I have a memory explosion, and
> > I'm running with 2GB given to the VM process. I'll try giving a bit
> > more, but my poor system doesn't have too much RAM to spare :(
> >
> > On 07/04/2012 08:28 AM, Marc-Andre Laverdiere-Papineau wrote:
> >> Hello,
> >>
> >> I can get going along those lines. I only have one big big piece missing
> >> in the puzzle.
> >>
> >> How do I set the entry points in the second phase?
> >> Even if I store them in a text file, I need to have the SootMethod
> >> objects. To get those, I need to have the classpaths and process dirs
> >> set, and to use loadNecessaryClasses(), etc. Won't that give me problems
> >> later on?
> >> Unless there is a special command-line option I missed.
> >>
> >> As an alternative implementation, is there an easy-ish way of extending
> >> the entry point detection algorithm for my use case?
> >>
> >> On 07/04/2012 03:59 AM, Eric Bodden wrote:
> >>> Hello.
> >>>
> >>> Ok, I see your use case now. However, you have to keep in mind the
> following:
> >>> At the time you search for entry points, you have not yet conducted a
> >>> whole-program analysis. Hence, at this point it is unclear what your
> >>> whole program actually is. At this time, it does not make much sense
> >>> to ask the hierarchy for subclasses because the hierarchy does not yet
> >>> know the universe of all classes to be considered. This is kind of a
> >>> chicken/egg problem. Here is a possible other solution that I can see:
> >>>
> >>> Use process-dir to process all classes in your jar(s). At this time,
> >>> scann all classes, one by one, checking if the class is a subclass of
> >>> javax.servlet.http.HttpServlet and contains one of the methods you are
> >>> looking for. Do not use the hierarchy. Store a table of those methods.
> >>>
> >>> Then reset Soot, and now run it in whole-program mode. As entry
> >>> points, choose the methods computed above.
> >>>
> >>> I think this should work. If not, let us know.
> >>>
> >>> Eric
> >>>
> >>> On 3 July 2012 18:11, Marc-Andre Laverdiere-Papineau
> >>> <marc-andre.laverdiere-papineau at polymtl.ca> wrote:
> >>>> Hello,
> >>>>
> >>>> I work with servlet entry points. I find all classes that are
> subclasses
> >>>> of HttpServlet and then the doGet, etc. methods
> >>>>
> >>>> Code is like this:
> >>>>
> >>>> final SootClass servletClass =
> >>>> Scene.v().loadClassAndSupport("javax.servlet.http.HttpServlet");
> >>>>
> >>>> FastHierarchy fh = Scene.v().getOrMakeFastHierarchy();
> >>>> final String[] servletMethods = new String[]{
> >>>> //HTTP Servlet
> >>>> "doGet", "doPost", "doPut", "doDelete", "init", "destroy",
> >>>> "getServletInfo",
> >>>> //From JspC
> >>>> "_jspInit", "_jspDestroy", "_jspService"
> >>>> };
> >>>> for (SootClass sc : Scene.v().getApplicationClasses()){
> >>>> if (!sc.isInterface() && fh.isSubclass(sc, servletClass)){
> >>>> logger.debug("Servlet detected: {}", sc.toString());
> >>>> for(String method : servletMethods){
> >>>> if (sc.declaresMethodByName(method))
> >>>> entryPoints.add(sc.getMethodByName(method));
> >>>> }
> >>>> }
> >>>> }
> >>>>
> >>>> On 2012-07-03 11:51, Eric Bodden wrote:
> >>>>> Hi all.
> >>>>>
> >>>>> G.reset() resets all static state. But that's not Marc-Andre's
> >>>>> problem. His problem is that Soot also releases all the method bodies
> >>>>> after they were written out. Calling G.reset() does not undo this
> >>>>> "garbage collection".
> >>>>>
> >>>>> Marc: How do you compute entry points, i.e., based on which
> conditions?
> >>>>>
> >>>>> Eric
> >>>>>
> >>>>> On 3 July 2012 16:45, Patrick Lam <p.lam at ece.uwaterloo.ca> wrote:
> >>>>>> On 07/03/2012 10:20 AM, Marc-Andre Laverdiere-Papineau wrote:
> >>>>>>> So what would be the proper way of picking my entry points then?
> >>>>>>
> >>>>>> G.reset() ought to work, but maybe it doesn't. You could run Soot
> once,
> >>>>>> save the results, quit the JVM, and run Soot again, loading the
> results.
> >>>>>> At least that will tell you if it works or not.
> >>>>>>
> >>>>>> pat
> >>>>>> _______________________________________________
> >>>>>> Soot-list mailing list
> >>>>>> Soot-list at sable.mcgill.ca
> >>>>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Marc-André Laverdière-Papineau
> >>>> Étudiant au doctorat - PhD Student
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Soot-list mailing list
> >>>> Soot-list at sable.mcgill.ca
> >>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>
> --
> Marc-André Laverdière-Papineau
> Étudiant au doctorat - PhD Student
>
>
> _______________________________________________
> 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/20120704/3c48b33f/attachment-0001.html
More information about the Soot-list
mailing list