[Soot-list] Soot-list Digest, Vol 52, Issue 2

Sun Aug 2 15:16:05 EDT 2009

Dear Eric:
    I am new using spark, while I am trying to understand this high
quality framework,I met with some problems, Can you give me some
suggestions? Sorry for bring you troubles recently.
subject:
    simplified around() pointcut pattern:
   A() {D{r1}}
   B(){D{r2}}
   C(){D(r3)}
   D(Interface r){r.run()}

   while I am analyzing A(), I need to query the targets, using
context-sensitive analysis, it would tell us that A() would call
r1.run()
   But for context-insensitive analysis, r potentially points to r1,r2,r3.
so r1.run(),r2.run(),r3.run() would all be possible targets.

problem1:
    Is DemandCSPoints a context-sensitive point to analysis? I remembered
spark implements no context-sensitive pointto analysis. But the name
"DemandCS" means context-sensitive.
Problem2:
    From the sparkTransformer, I know DemandCSPoint refines after the
on-the-fly call graph build(), then DemandCSPointTo will only refine
point to relationship, it will not influence the call graph.
Am I right? And, what is more important, Can DemandCSPoint tell me exactly
in the upper case, A() will call r1.run()?

I should have got this answer myself  by playing with the code. but I use
	CallGraph cg = Scene.v().getCallGraph();
	TransitiveTargets tt = new TransitiveTargets( cg );
	Iterator<MethodOrMethodContext> it = tt.iterator( stmt );// all
transitive targets
and I do not get things on the aj project. But successfully return targets
for other test programs.
And I find codes are too many for me to understand in a short while. So
can you give me suggestion about the above two problems ?

  Thanks
  Regards.
Peng

> Send Soot-list mailing list submissions to
> 	soot-list at sable.mcgill.ca
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> or, via email, send a message with subject or body 'help' to
> 	soot-list-request at sable.mcgill.ca
>
> You can reach the person managing the list at
> 	soot-list-owner at sable.mcgill.ca
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Soot-list digest..."
>
>
> Today's Topics:
>
>    1. Re: Soot-list Digest, Vol 51, Issue 29 (Eric Bodden)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 2 Aug 2009 13:33:00 +0200
> From: Eric Bodden <eric.bodden at mail.mcgill.ca>
> Subject: Re: [Soot-list] Soot-list Digest, Vol 51, Issue 29
> To: LIU Peng <lpxz at ust.hk>
> Cc: soot-list at sable.mcgill.ca
> Message-ID:
> 	<804e3c660908020433h648c72cei2accbf4a3d98c5b1 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Peng.
>
> This, to me, looks like a bug in the type assigner. Can you try to run
> Soot with the following command-line option and see if you still get
> the same exception?
>
> -p jb.tr use-older-type-assigner:true
>
> This will us a different implementation for the type assigner.
>
> Also, can you please open a bug report
> https://svn.sable.mcgill.ca/bugzilla/ and attach to the report the
> AspectJ program and the command line that you use to run Soot?
>
> Thanks,
> Eric
>
> 2009/8/1 LIU Peng <lpxz at ust.hk>:
>> Hello :
>> ? ? I met with an exception while analyzing programs written using
>> Aspectj.
>> I find where it bring me an exception, But I do not why such case
>> happens.
>> Can you help me understand it?
>>
>> Trace:
>>
>> java.lang.RuntimeException: Attempt to create VarNode of type
>> bottom_type
>> ? ? ? ?at soot.jimple.spark.pag.VarNode.<init>(VarNode.java:90)
>> ? ? ? ?at
>> soot.jimple.spark.pag.LocalVarNode.<init>(LocalVarNode.java:43)
>> ? ? ? ?at soot.jimple.spark.pag.PAG.makeLocalVarNode(PAG.java:499)
>> ? ? ? ?at
>> soot.jimple.spark.builder.MethodNodeFactory.caseLocal(MethodNodeFactory.java:217)
>> ? ? ? ?at soot.jimple.internal.JimpleLocal.apply(JimpleLocal.java:135)
>> ? ? ? ?at
>> soot.jimple.spark.builder.MethodNodeFactory$1.caseAssignStmt(MethodNodeFactory.java:75)
>> ? ? ? ?at soot.jimple.internal.JAssignStmt.apply(JAssignStmt.java:236)
>> ? ? ? ?at
>> soot.jimple.spark.builder.MethodNodeFactory.handleStmt(MethodNodeFactory.java:67)
>> ? ? ? ?at
>> soot.jimple.spark.pag.MethodPAG.buildNormal(MethodPAG.java:167)
>> ? ? ? ?at soot.jimple.spark.pag.MethodPAG.build(MethodPAG.java:133)
>> ? ? ? ?at
>> soot.jimple.spark.solver.OnFlyCallGraph.processReachables(OnFlyCallGraph.java:64)
>> ? ? ? ?at
>> soot.jimple.spark.solver.OnFlyCallGraph.build(OnFlyCallGraph.java:56)
>> ? ? ? ?at
>> soot.jimple.spark.solver.PropWorklist.handleVarNode(PropWorklist.java:125)
>> ? ? ? ?at
>> soot.jimple.spark.solver.PropWorklist.propagate(PropWorklist.java:54)
>> ? ? ? ?at
>> soot.jimple.spark.SparkTransformer.internalTransform(SparkTransformer.java:152)
>> ? ? ? ?at soot.SceneTransformer.transform(SceneTransformer.java:39)
>> ? ? ? ?at soot.Transform.apply(Transform.java:89)
>> ? ? ? ?at soot.RadioScenePack.internalApply(RadioScenePack.java:58)
>> ? ? ? ?at
>> soot.jimple.toolkits.callgraph.CallGraphPack.internalApply(CallGraphPack.java:48)
>> ? ? ? ?at soot.Pack.apply(Pack.java:114)
>> ? ? ? ?at soot.PackManager.runWholeProgramPacks(PackManager.java:409)
>> ? ? ? ?at soot.PackManager.runPacks(PackManager.java:330)
>>
>>
>> I find the source of the exception:
>> l0
>> <dstm2.benchmark.aj.List: void init()>
>>
>>
>> l0 in init() is like this:
>> ?protected void init()
>> ? ?{
>>
>> ? ? ? ?bottom_type l0;
>>
>> ? ? ? ?l3 = newarray (java.lang.Object)[1];
>> ? ? ? ?l3[0] = l0;
>> ? ? ? ?$r1 = new dstm2.benchmark.aj.List$AjcClosure1;
>> ? ? ? ?specialinvoke $r1.<dstm2.benchmark.aj.List$AjcClosure1: void
>> <init>(java.lang.Object[])>(l3);
>> ...
>> ? ? }
>>
>> ajcClosure.<init>() is used to initialize ajcClosure, and l3 is expected
>> to initialize the state of ajcClosure.
>>
>> But why does l0 is bottom_type, I am not familiar with the underlying
>> matters of AOP, can you give me an example when this happens?
>>
>> Thanks
>> Regards
>> Peng
>>
>>
>>
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
>
>
>
> --
> Eric Bodden
> Software Technology Group
> Technical University Darmstadt, Germany
>
>
> ------------------------------
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
>
> End of Soot-list Digest, Vol 52, Issue 2
> ****************************************
>