[Soot-list] ExceptionalUnitGraph and nested traps
Michael Faes
rolve at trick17.ch
Mon Dec 31 09:29:35 EST 2012
Hi everyone,
I'm going to use Soot (2.5.0) for a deadlock analysis as part of my
Master's thesis and I'm currently experimenting with the data flow
analysis framework and the ExceptionalUnitGraph.
Here is my problem: I found that if there are any nested traps around a
statement, the ExceptionalUnitGraph has edges from that statement to
both trap handlers instead of only to the inner one.
Here is an example. This method:
public void foo() {
synchronized(TestClass.class) {
synchronized(this) {
System.currentTimeMillis();
}
}
}
is converted to Jimple like this:
public void foo()
{
deadlockfinder.test.TestClass r0, r3;
java.lang.Class $r1, r2;
java.lang.Throwable $r5, $r6;
r0 := @this: deadlockfinder.test.TestClass;
$r1 = class "deadlockfinder/test/TestClass";
r2 = $r1;
entermonitor $r1;
label0:
r3 = r0;
entermonitor r0;
label1:
staticinvoke <java.lang.System: long currentTimeMillis()>();
exitmonitor r3;
label2:
goto label6;
label3:
$r5 := @caughtexception;
label4:
exitmonitor r3;
label5:
throw $r5;
label6:
exitmonitor r2;
label7:
goto label11;
label8:
$r6 := @caughtexception;
label9:
exitmonitor r2;
label10:
throw $r6;
label11:
return;
catch java.lang.Throwable from label1 to label2 with label3;
catch java.lang.Throwable from label4 to label5 with label3;
catch java.lang.Throwable from label0 to label7 with label8;
catch java.lang.Throwable from label9 to label10 with label8;
}
Note the trap that spans from label1 to 2 and the one that spans from
label0 to 7.
When printing the predecessors of each statement, I get the following
for the statement "$r6 := @caughtexception;" after label8:
exitmonitor r3
goto [?= exitmonitor r2]
$r6 := @caughtexception
exitmonitor r2
r3 = r0
entermonitor r0
exitmonitor r3
throw $r5
$r5 := @caughtexception
exitmonitor r2
entermonitor $r1
staticinvoke <java.lang.System: long currentTimeMillis()>()
^^^
As you can see, the graph adds the possibility to go from
currentTimeMillis() directly to the outer trap handler. Because of this,
my deadlock analysis concludes that it is possible for a thread to leave
this method without unlocking "this".
Now, my questions: Am I right that this is undesired behavior? Is there
a way to fix this?
Thank you so much in advance.
Best regards,
Michael
More information about the Soot-list
mailing list