[Soot-list] duplicate subgraphs in CFG

[hsadat at gmail.com]

Thanks Eric and Martin,

After running soot on the class files of the same method, I noticed  
that the CFG looks correct.
In fact, there are no exceptional edges from the finally-block nodes.  
I checked the Jimple code
and it's consistent with the CFG: there's no handler for the finally- 
block; so if an exception occurs,
it's propagated to the caller.

So, you are right. When byte code is used to generate Jimple, things  
seem to be correct.

--Hossein

P.S. I posted an annotated CFG that has not made it through to the  
mailing list because of its size. Let me know,
if you're interested to see it.



On 22-Jan-09, at 9:06 AM, Eric Bodden wrote:

> Thanks Martin.
>
> Indeed I suspect an error in the Java2Jimple frontend that Soot uses.
> When you process bytecode with Soot then this frontend is not being
> used.
>
> Eric
>
> 2009/1/22 Martin Bravenboer <martin.bravenboer at gmail.com>:
>> Hi Hossein & Eric,
>>
>> I'm not using the Soot Eclipse plugin, so I don't know if this code  
>> is
>> compiled by the Eclipse compiler or one of the Soot front-ends?
>>
>> Anyway, it seems an issue specific to one of these compilers. If you
>> compile the code with javac, and use Soot to produce Jimple, then you
>> get this:
>>
>> ---------------------------------------------------------------------
>>   public static void main(java.lang.String[])
>>   {
>>       java.lang.String[] r0;
>>       java.io.PrintWriter r1, $r4;
>>       java.io.IOException r2, $r5;
>>       java.lang.Throwable r3, $r8;
>>       java.io.PrintStream $r6;
>>       java.lang.String $r7;
>>
>>       r0 := @parameter0: java.lang.String[];
>>       r1 = null;
>>
>>    label0:
>>       $r4 = new java.io.PrintWriter;
>>       specialinvoke $r4.<java.io.PrintWriter: void
>> <init>(java.lang.String)>("out.txt");
>>       r1 = $r4;
>>       virtualinvoke r1.<java.io.PrintWriter: void
>> println(java.lang.String)>("something");
>>
>>    label1:
>>       if r1 == null goto label9;
>>
>>       virtualinvoke r1.<java.io.PrintWriter: void close()>();
>>       goto label9;
>>
>>    label2:
>>       $r5 := @caughtexception;
>>
>>    label3:
>>       r2 = $r5;
>>       $r6 = <java.lang.System: java.io.PrintStream out>;
>>       $r7 = virtualinvoke r2.<java.io.IOException: java.lang.String
>> getMessage()>();
>>       virtualinvoke $r6.<java.io.PrintStream: void
>> println(java.lang.String)>($r7);
>>
>>    label4:
>>       if r1 == null goto label9;
>>
>>       virtualinvoke r1.<java.io.PrintWriter: void close()>();
>>       goto label9;
>>
>>    label5:
>>       $r8 := @caughtexception;
>>
>>    label6:
>>       r3 = $r8;
>>
>>    label7:
>>       if r1 == null goto label8;
>>
>>       virtualinvoke r1.<java.io.PrintWriter: void close()>();
>>
>>    label8:
>>       throw r3;
>>
>>    label9:
>>       return;
>>
>>       catch java.io.IOException from label0 to label1 with label2;
>>       catch java.lang.Throwable from label0 to label1 with label5;
>>       catch java.lang.Throwable from label3 to label4 with label5;
>>       catch java.lang.Throwable from label6 to label7 with label5;
>>   }
>> }
>> ---------------------------------------------------------------------
>>
>> This is correct:
>>
>>    label0: try code
>>    label1: finally code for successful try
>>    label2: exception handler for try (IOException)
>>    label3: catch code
>>    label4: finally code for successful catch
>>    label5: exception handler for try (all Throwable not IOException)
>> and any throwable in catch
>>    label7: finally code for failure in try or failure in catch
>>
>> The handlers:
>>
>>       catch java.io.IOException from label0 to label1 with label2;
>>
>> IOException in try code -> goto catch
>>
>>       catch java.lang.Throwable from label0 to label1 with label5;
>>
>> Throwable in try code -> goto finally
>>
>>       catch java.lang.Throwable from label3 to label4 with label5;
>>
>> Throwable in catch code -> goto finally
>>
>>       catch java.lang.Throwable from label6 to label7 with label5;
>>
>> This exception handler is always generated by javac and seems to
>> handle corner cases. It covers astore_2 only, which can only throw
>> asynchronous exceptions (the instructions itself doesn't throw
>> anything). It retries the finally clause if an exception occurs.
>>
>> Cheers,
>> --
>> Martin Bravenboer
>> ---------------------------------------------------------------------
>> Department of Computer Science
>> University of Massachusetts Amherst
>>
>
>
>
> -- 
> Eric Bodden
> Sable Research Group, McGill University
> Montréal, Québec, Canada