[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