[Soot-list] duplicate subgraphs in CFG

[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/