[Soot-list] Call Graph with non-static entry points?

[Bernhard Berger]

Hi,

the problem I observed had to do with calls to methods of the same instance. e.g.:

void entryPoint(Param entryParameter) {
  this.foo();
}

The call to foo was missing in the resulting call graph. It would be very logical to say that spark has got now information about this and therefore fails to resolve the call. That was the conclusions I made and solved my problem by generating a "correct" main method that generates an instance and respects the lifecycle of the managed object.

Bernhard

Am 11.01.2013 um 04:45 schrieb Laurie Hendren <hendren at cs.mcgill.ca>:

> Hi Marc-Andre,
> 
> I would have to look to see why that would be a problem,  but it may 
> have to do with needing a concrete object for the receiver.     In fact, 
> if your entry points are not static, doesn't some method need to create 
> an object on which it calls your entry point ..
> 
> If so, then wouldn't you just have to create a dummy static method that 
> creates an object and makes the call,  and then start the call graph 
> algorithm at the dummy static method?
> 
> Or ... am I misunderstanding your question?
> 
> Laurie
> 
> 
> 
> +--------------------------------------------------------------
> | Laurie Hendren --- http://www.sable.mcgill.ca/~hendren
> | Associate Dean (Academic), Faculty of Science
> | Professor, School of Computer Science, McGill University
> | New McLAB project:  http://www.sable.mcgill.ca/mclab/
> | Also: www.sable.mcgill.ca/soot  www.sable.mcgill.ca/abc
> +--------------------------------------------------------------
> 
> On 10/01/2013 10:30 PM, Marc-Andre Laverdiere-Papineau wrote:
>> Hello,
>> 
>> Chatting with Bernhard yesterday, he was telling me that there are
>> problems with Spark when the entry points are not static.
>> 
>> Since my entry point detection framework is very good at detecting
>> non-static things, I am wondering if that is making the framework moot.
>> 
>> Can anyone confirm whether Spark, or call graph constructions algorithms
>> in general, have an assumption concerning the type of entry points it is
>> dealing with? Or should that be considered as a bug that we'll fix along
>> the way?
>> 
>> Regards,
>> 
> 
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list