[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