[Soot-list] NullPointerException in soot.SootMethod.getBodyFromMethodSource
Marc-Andre Laverdiere-Papineau
marc-andre.laverdiere-papineau at polymtl.ca
Wed Jul 4 23:31:03 EDT 2012
Hello Phil,
I am attaching the source code of the latest variant, which is giving
this field resolution error, and the older one, which was using the
class hierarchy.
The classpath is dependent a lot of what Maven in Eclipse does, so I
don't know how well that'd work on the CLI or in another IDE.
I put the test files on RapidShare. You can get that here:
https://rapidshare.com/files/4199596445/alfresco.tar.bz2
Maybe it would be a good idea if we could look at things on IRC or any
mechanism that is a bit more 'live'? Let me know by private email.
Regards,
--
Marc-André Laverdière-Papineau
Étudiant au doctorat - PhD Student
On 07/04/2012 09:46 PM, Phil Pratt-Szeliga wrote:
> 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
> <mailto: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
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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 <mailto:Soot-list at sable.mcgill.ca>
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pom.xml
Type: text/xml
Size: 2892 bytes
Desc: not available
Url : http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20120704/5a41980c/attachment-0001.xml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OldSootMain.java
Type: text/x-java
Size: 7565 bytes
Desc: not available
Url : http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20120704/5a41980c/attachment-0003.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PathUtils.java
Type: text/x-java
Size: 1885 bytes
Desc: not available
Url : http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20120704/5a41980c/attachment-0004.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SootMain.java
Type: text/x-java
Size: 9184 bytes
Desc: not available
Url : http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20120704/5a41980c/attachment-0005.bin
More information about the Soot-list
mailing list