[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: your mail



On Sun, Mar 23, 2003 at 11:08:12AM -0500, Eran Yahav wrote:
> I'm using
> "soot.jimple.toolkits.invoke.MethodCallGraph.getMethodsReachableFrom(methodCollection)"
> to get a collection of methods reachable from a "start-method" in
> the application. It seems that this does not take multithreading
> into account, and methods of threads started by the start-method
> are not included in the resulting collection.
> 
> I understand that the run() method of the started threads is never
> explicitly invoked from the start-method, which may pose a problem in
> using the MethodCallGraph.
> 
> - Is there an alternative API for obtaining the collection of ALL
> reachable methods?

Nothing like that exists in the current version of Soot. However, this
week, we are planning to start designing a new representation of the
call graph that would include information about implicit calls, such as
those due to the start() methods, other native methods, and reflection.
This would hopefully appear in some future version of Soot. Any input
would be welcome.

> - Its probably possible to get all implemented "run()" methods in
> subclasses of class Thread or classes implementing Runnable, and check
> which one of these may be (implicitly) invoked from the start-method,
> collection of ALL reachable methods can be then obtained by calling
> getMethodsReachableFrom with a collection containing these run()
> methods. However, I would like to avoid such brute-force technique if
> possible. 

You can use the Hierarchy to get all the subclasses of Thread, then look
for run() methods. I agree that this is annoying, which is why we are
planning a better invoke graph representation.

Ondrej

> 
> Thanks,
> Eran
> 
> 
> 
> ----------------------------------------------------------------------------
> Eran Yahav                 | Two types have compatible type 
> yahave@post.tau.ac.il      | if their types are the same.
> www.cs.tau.ac.il/~yahave   | -- ANSI C Standard, 3.1.2.6.
> ----------------------------------------------------------------------------