[Soot-list] CFG and exception analysis

Irem Aktug irem at nada.kth.se
Fri Apr 18 06:03:01 EDT 2008


Hello!

This seems to be my favorite subject. I will look at the technical 
report again. But I want to get opinions as well.

I am creating a control-flow graph taking exceptional flow into account.

I have a code that looks something like this:


try {
       Scheduler.schedule();
}

catch (SimulationException e){
}


My  CFG looks a little different than what soot creates so  I try to 
adapt soot CFGs in my program. I consider only exceptions of subtypes of 
class Exception into account. I also do not consider IllegalMonitorState 
and assume for now no MT is present in my exceptional analysis.

My problem is the following: Scheduler.schedule is a static method 
invocation. Reading the JVM specification I see that invokestatic may 
throw errors like |IncompatibleClassChangeError|, |UnsatisfiedLinkError| 
etc. Yet, in my flow graph it looks like invokestatic may throw a 
Throwable. And I get an edge as if the exception thrown by invokestatic 
(and not the called method) is handled by the handler above. Yet 
SimulationException is an application defined exception.

My first question is a little off limits... I am just wondering... Take 
an instruction (not a method call of course) that may throw for instance 
NullPointerException. And assume that there is an application defined 
exception class that inherits from this exception type. Shouldn't the 
control flow graph have an exceptional destination for 
(NullPointerException)-(UserDefinedException)? This kind of analysis I 
can guess would take time. But I am asking nonetheless.

My objective is to seperate between exceptions thrown by the invocation 
instruction and the invoked method itself. So that in  my graph there 
will be two edges ending in exceptions, only one labeled with the called 
method. So I want to make sure that this Throwable exceptional 
destination is indeed for the invocation instruction and not the invoked 
method. Is this the case?

If it is not, then I will safely(?) assume that invokestatic does not 
raise any exceptions of type  Exception or its subclasses, making my 
flow graph a little finer.

Irem

ps. Now off to that great technical report on exceptional analysis in soot



More information about the Soot-list mailing list