[Soot-list] duplicate subgraphs in CFG

[Eric Bodden]

Hossein,

I tried to reproduce this but I don"t quite see the edge(s) you are
referring to.

Could you give some more details, maybe an annotated screenshot?

Eric

2009/1/9  <hsadat at gmail.com>:
> 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/
>
>
> _______________________________________________
> 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, Québec, Canada