[Soot-list] duplicate subgraphs in CFG
Eric Bodden
eric.bodden at mail.mcgill.ca
Thu Jan 22 10:14:25 EST 2009
Indeed there seems to be something odd going on.
Below is the Jimple code that Soot generates for you main method. From
what I understand, the trap "catch java.lang.Throwable from label1 to
label5 with label8;" seems to be the problem. It should be from label1
to label4 actually, so that it does not span the catch block. Is that
what you are saying?
Eric
public static void main(java.lang.String[])
{
java.lang.String[] args;
java.io.PrintWriter pr, temp$0;
java.lang.Object data, temp$1;
java.io.IOException e;
java.io.PrintStream temp$2;
java.lang.String temp$3;
java.lang.Throwable temp$4;
args := @parameter0: java.lang.String[];
pr = null;
label0:
nop;
temp$0 = new java.io.PrintWriter;
specialinvoke temp$0.<java.io.PrintWriter: void
<init>(java.lang.String)>("out.txt");
pr = temp$0;
virtualinvoke pr.<java.io.PrintWriter: void
println(java.lang.String)>("Begin Printing ...");
temp$1 = staticinvoke <snippet.Snippet: java.lang.Object getData()>();
data = temp$1;
virtualinvoke pr.<java.io.PrintWriter: void
print(java.lang.Object)>(data);
label1:
nop;
if pr != null goto label2;
goto label3;
label2:
nop;
virtualinvoke pr.<java.io.PrintWriter: void close()>();
label3:
nop;
goto label11;
label4:
nop;
e := @caughtexception;
temp$2 = <java.lang.System: java.io.PrintStream out>;
temp$3 = virtualinvoke e.<java.io.IOException:
java.lang.String getMessage()>();
virtualinvoke temp$2.<java.io.PrintStream: void
println(java.lang.String)>(temp$3);
label5:
nop;
if pr != null goto label6;
goto label7;
label6:
nop;
virtualinvoke pr.<java.io.PrintWriter: void close()>();
label7:
nop;
goto label11;
label8:
nop;
temp$4 := @caughtexception;
if pr != null goto label9;
goto label10;
label9:
nop;
virtualinvoke pr.<java.io.PrintWriter: void close()>();
label10:
nop;
throw temp$4;
label11:
nop;
return;
catch java.io.IOException from label0 to label1 with label4;
catch java.lang.Throwable from label0 to label1 with label8;
catch java.lang.Throwable from label1 to label5 with label8;
}
2009/1/21 <hsadat at gmail.com>:
> Hi Eric,
> Attached please find an annotated image of part of the CFG of the following
> method:
> PrintWriter pr = null;
> try{
>
> pr = new PrintWriter("out.txt");
> pr.println("Begin Printing ...");
> Object data = getData();
> pr.print(data);
> }
> catch(IOException e)
> {
> System.out.println(e.getMessage());
> }
> finally{
> if(pr != null)
> pr.close();
> }
>
> sorry if the annotations look goofy. The red arrow is what doesn't make
> sense to me: exceptional edges from the finally block to the
> exceptional-flow finally block.
>
> Thanks for your time.
>
> --Hossein
>
> On 20-Jan-09, at 9:51 AM, Eric Bodden wrote:
>
> 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
>
>
--
Eric Bodden
Sable Research Group, McGill University
Montréal, Québec, Canada
More information about the Soot-list
mailing list