[Soot-list] Call graph behavior with interfaces and no concrete implementations

[Hal Hildebrand]

On Aug 12, 2010, at 12:15 AM, Eric Bodden wrote:

> On 12 August 2010 00:55, Hal Hildebrand <hal.hildebrand at gmail.com> wrote:
>> Is there something I can do, or something I'm doing which I shouldn't, which would make this scenario work with Soot?
> 
> Hi Hal.
> 
> First of all: This is intended behavior. Soot performs a whole-program
> analysis, which means that it assumes that you provide the whole
> program. In your specific case, I don't think that the issue is
> actually that Y is an interface. You would also see no call edge if Y
> was just a class. The problem is that the field X.y is never
> initialized. This makes Soot assume that the field will always be null
> and that therefore the call to y.foo() can never happen.

That is exactly what I originally thought.  However, the behavior I see is that I do, in fact, get Y.foo() as an outbound edge of X.b() if and only if I include a concrete implementation of Y.  Again, note that in this scenario, I have not actually initialized the field in X.y - i.e. the only change is providing a concrete implementation of Y.  This is why I'm at a loss to explain what's happening under the covers.  My model for how things should be working is precisely what you described - that it isn't throws my internal model for a loop.

> 
> To deal with this properly I think that you would actually have to
> change the way Spark builds its pointer-assignment graph. You can find
> all the information about how this graph is build in Ondrej Lhotak's
> Master's thesis.

After some thought about this last night, I think I'm going to resort back to my original inference scheme, which doesn't really require a call graph.  I can still hook into the scene transformer and iterate until I reach a fixed point on the inference, examining the method calls within a method.  I think the only real issue I'll have will be ensuring that I have the right annotation information on the methods that don't form the application set (assuming that I still use the set_no_bodies_for_excluded option to eliminate the processing of non application classes).  That should allow me to leverage Soot more effectively.  I can then isolate the inference and turn that into an optimization issue to solve later, which would be nice.

Again, thanks for your help.

Hal