[Soot-list] duplicate subgraphs in CFG
hsadat at gmail.com
hsadat at gmail.com
Fri Jan 9 20:52:23 EST 2009
Hi,
I have noticed something strange (and possibly semantically incorrect)
that might be one of the side-effects (not sure though) of previously
discussed duplication of finally-block's CFG.
My understanding of Java semantics says that if an exception is raised
within the finally block, the method will throw the exception up to
its caller. What I see in the generated CFG is that, there are edges
(I assume exceptional edged) from the nodes of the normal-path finally
block to the beginning of the exceptional-path finally block; that
means, if an exception is raised within the finally block, the finally
block would be executed again, and eventually throwing the exception.
Here the example I used:
PrintWriter pr = null;
try{
pr = new PrintWriter("out.txt");
pr.println("something");
}
catch(IOException e)
{
System.out.println(e.getMessage());
}
finally{
if(pr != null)
pr.close();
}
I was wondering:
1) Am I missing something?
2) Has anyone else observed this? or anything that could be related to
this?
3) If this is a known issue, is there any build that fixes this?
I'm using Soot plugin 2.3.0 for Eclipse 3.3.2.
Thanks in advance for your time.
--Hossein
On 5-Dec-08, at 6:32 AM, Eric Bodden wrote:
> Fair enough. Just to let you know: In most cases you actually may want
> to use an ExceptionalUnitGraph, not a BriefUnitGraph, as the latter
> omit crucial exceptional flow.
>
> Eric
>
> 2008/12/4 <hsadat at gmail.com>:
>> No worries. Thanks for looking into it.
>>
>> So far, I haven't really been doing anything with these CFGs; just
>> trying to
>> understand the various forms they take in soot. So, I really can't
>> tell if
>> this is going to cause any problems. Hopefully, none :)
>>
>> Thanks again.
>>
>> --Hossein
>>
>> On 4-Dec-08, at 9:16 PM, Eric Bodden wrote:
>>
>>> I am sorry but I am not sure why this happens. Interesting
>>> observation... Anyway, is that a problem for you?
>>>
>>> Eric
>>>
>>> 2008/12/4 <hsadat at gmail.com>:
>>>>
>>>> Thanks Eric.
>>>>
>>>> You're right. Actually, I was partly confused because I had no
>>>> "throw"-ending path in the CFG; but after I scrolled to the
>>>> right, it was
>>>> right there! (I'm using brief CFG, so, I get a forest.)
>>>>
>>>> Now, what you said explains the duplication for "normal" and
>>>> "exceptional"
>>>> paths; however, the subgraph is also duplicated for two different
>>>> paths
>>>> that
>>>> both merge into normal return. Here is my example (see the
>>>> attached png
>>>> for
>>>> the CFG):
>>>>
>>>> try{
>>>> f();
>>>> }
>>>> catch(IOException)
>>>> {
>>>> g();
>>>> }
>>>> finally{
>>>> h();
>>>> }
>>>>
>>>> Please see the attached CFG.
>>>>
>>>> So, the flow from catch (handled exception) and try (normal flow)
>>>> both
>>>> merge
>>>> into finally block. Therefore, there's no need for duplicate h()
>>>> nodes
>>>> for
>>>> these two paths. Am I missing another thing? (Sorry if I'm asking
>>>> dumb
>>>> questions ...)
>>>>
>>>> --Hossein
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 4-Dec-08, at 5:43 PM, Eric Bodden wrote:
>>>>
>>>>> The duplication is simply to implement the correct semantics. If
>>>>> you
>>>>> have...
>>>>>
>>>>> try{
>>>>> foo();
>>>>> } finally {
>>>>> bar();
>>>>> }
>>>>>
>>>>> ... then you need something like ...
>>>>>
>>>>> label1:
>>>>> foo();
>>>>> label2:
>>>>> bar();
>>>>> return;
>>>>> label3:
>>>>> e = @caughtexception;
>>>>> bar();
>>>>> throw e;
>>>>>
>>>>> trap Throwable from label1 to label2 with label3;
>>>>>
>>>>> ... on the Jimple level because you want to execute bar()
>>>>> *regardless*
>>>>> of the exception being thrown, but you obviously want to return
>>>>> *or*
>>>>> throw depending on whether an exception was raised within the try
>>>>> block. The label/location of the copied block therefore sort of
>>>>> encodes the information "exception" or "no exception".
>>>>>
>>>>> Eric
>>>>>
>>>>>
>>>>>
>>>>> 2008/12/4 <hsadat at gmail.com>:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I was looking at the CFGs built in interactive mode using Soot
>>>>>> Eclipse
>>>>>> plugin and noticed that there are some duplicate subgraphs;
>>>>>> specifically,
>>>>>> the subgraph corresponding to "finally" block is repeated, one
>>>>>> for the
>>>>>> path
>>>>>> from the end of the catch block and the other for the path from
>>>>>> end of
>>>>>> try
>>>>>> block. Has anyone encountered this? and is there an explanation
>>>>>> behind
>>>>>> it?
>>>>>>
>>>>>> I tried to think of possible reasons for duplicating; because I
>>>>>> know in
>>>>>> the
>>>>>> analysis context, some of the nodes are created to make later
>>>>>> analysis/transformation easier (e.g. "nop" nodes).
>>>>>>
>>>>>> So, any clues?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> --Hossein
>>>>>> _______________________________________________
>>>>>> Soot-list mailing list
>>>>>> Soot-list at sable.mcgill.ca
>>>>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Eric Bodden
>>>>> Sable Research Group, McGill University, Montréal, Canada
>>>>> Got an interesting job offer? http://www.bodden.de/hire-me/
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Eric Bodden
>>> Sable Research Group, McGill University, Montréal, Canada
>>> Got an interesting job offer? http://www.bodden.de/hire-me/
>>
>>
>
>
>
> --
> Eric Bodden
> Sable Research Group, McGill University, Montréal, Canada
> Got an interesting job offer? http://www.bodden.de/hire-me/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20090109/bd73340b/attachment-0001.html
More information about the Soot-list
mailing list