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

[Marc-Andre Laverdiere-Papineau]

Hello Laurie,

In general, JEE sort of breaks all the rules, as the container (the JEE 
application server) is in charge of all this stuff for you. What that 
means is that the programmer codes against a spec (the javaee-api jar is 
all interfaces and stubs). So, the creation of the object that serves as 
entry point (e.g. a Servlet) is done by a piece of code outside the 
analysis scope. Don't get me started on dependency injection :)

The brutal solution is to put the whole container in the scope - but 
that's near to 100 mb of jars - that's way too impractical.

The other solution is like what you suggested, a synthetic main. A 
problem is that it complicates the API - we need two entry point 
accessors now - one for the 'real' entry points, and another for 
starting the call graph construction algorithm - I can foresee people 
mixing the two and complaining about bugs in soot in this mailing list 
;) And this synthetic main needs to find the possible types - the target 
class and its subclasses.

I envision something that would work in a single run - that is why I 
coded entry point detectors. I am not sure that this synthetic main 
stuff would work in a single run (if so, I want to know how!)

 From what I had in the exchange with Bernhard, the problem is that we 
are not always sure what is the type of <this>. And that also means that 
we aren't sure what the calls are going to be like - to this class or a 
subclass' override?

So, in some cases, this lack of information is not a problem - we may 
not have subclasses. Or, if there are subclasses, we may go for a 
conservative estimate and have the call graph possibly call the same 
class or the subclasses' overrides.


P.S.
This could be a nice, self-contained and interesting summer project for 
interns - any takers? :)

Regards,

Marc-André Laverdière-Papineau
Doctorant - PhD Candidate

On 13-01-11 09:15 AM, Laurie Hendren wrote:
> 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
>