[prev in list] [next in list] [prev in thread] [next in thread] 

List:       soot-list
Subject:    Re: [Soot-list] ExceptionalUnitGraph and nested traps
From:       Patrick Lam <plam () sable ! mcgill ! ca>
Date:       2012-12-31 15:30:28
Message-ID: 50E1AF94.5090408 () sable ! mcgill ! ca
[Download RAW message or body]

Hi Michael,

It looks to me like the ExceptionalUnitGraph is conservatively reporting 
possible successor edges that never actually happen. That's not wrong, 
but it would be better if it were more precise. I suspect that there's 
no easy way to fix it short of fixing the ExceptionalUnitGraph creation 
code or running a subsequent pass to clean it.

pat

On 12/31/12 09:29, Michael Faes wrote:
> 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
> _______________________________________________
> Soot-list mailing list
> Soot-list@sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list

_______________________________________________
Soot-list mailing list
Soot-list@sable.mcgill.ca
http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
[prev in list] [next in list] [prev in thread] [next in thread]