[Soot-list] Incomplete Call Graph for Web Application

Marc-Andre Laverdiere-Papineau marc-andre.laverdiere-papineau at polymtl.ca
Thu Dec 13 05:09:08 EST 2012


Hi,

I read that paper and I'm glad that work is ongoing. A JEE server like 
glassfish has nearly 100mb of jars, so that's no fun for a static analyzer.

The thing that wouldn't help us is that its a priori algorithm, from 
what I recall. Spark's needs to be able to run on the fly with no a 
priori knowledge of the program or its libs.

So porting this to soot is not going to be trivial. And that's why its 
going to be even more awesome when we get it!

In the meantime, I can envision some post-processing of the call graph 
to add some edges as needed. That is _not_ a perfect solution, but I 
think I can prototype something fast that may help us all until the 
Waterloo call-graph-fu comes with the perfect solution :D

Regards,


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

On 12-12-13 02:05 PM, Eric Bodden wrote:
> Hello.
>
>> In other words, we'd need a call graph algorithm that can point to an
>> interface and leave it at that if need be. I don't recall a Spark option
>> to enable that. Any pointers to make it happen?
>
> I think many people are aware of this problem, and the problem is
> quite pressing, but not much research has been done in this area. The
> question is what can be done automatically if you really can assume
> nothing about the library except for it's API.
>
> Karim Ali and Ondrej Lhotak had a paper in that direction but it still
> extracts some knowledge about the API's implementation as far as I can
> recall:
> http://plg.uwaterloo.ca/~olhotak/pubs/ecoop12.pdf
>
> Ondrej, by the way, are you still planning on integrating this into Soot?
>
> Cheers,
> Eric
>


More information about the Soot-list mailing list