<div dir="ltr"><span style="font-size:12.8px">In one sense, the existence of multiple heads is not a bug, since it is deliberate design decision (and documented! See sections 2.4, 3.3.3, and 3.3.5 of </span><a href="http://www.sable.mcgill.ca/publications/techreports/sable-tr-2003-3.pdf" target="_blank" style="font-size:12.8px">the exceptions Tech Report</a><span style="font-size:12.8px">). I'll grant you it might be a bug in the sense of being a poor design decision.</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">It's been over a decade since I've done anything with Soot, so my knowledge is very stale. I'll point you to the technical report for a detailed explanation, while providing the basic intuition with reference to one of your examples.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">In the code</div><span class="gmail-im" style="font-size:12.8px"><div><br></div><div><div style="font-size:12.8px"><div>static {</div><div> try {</div><div> I1; ...; In;</div><div> } catch (...) {</div><div> J1; ...; Jn;</div><div> }</div><div>}</div><div><br></div></div></div></span><span style="font-size:12.8px">imagine that l1 is the instruction "int </span><span style="font-size:12.8px;color:rgb(0,0,0)">local0 = o.f". If o is a null pointer, instruction I1 will throw a null pointer exception and pass control to instruction J1 before anything is assigned to local0,</span><div style="font-size:12.8px"><span style="color:rgb(0,0,0)"><br></span></div><div style="font-size:12.8px"><span style="color:rgb(0,0,0)">So if you're using Soot to write a static analysis that characterizes the possible values of local0, that analysis has to be aware that when control reaches J1, the assignment at I1 did not happen. J1 can thus be the first instruction of the method to be completed successfully, which is the reason it is considered a possible head of the CFG.</span><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">Again, see section 2.4 of the technical report for a discussion of just what nodes and edges of the CFG mean.</span></div></div><div class="gmail-yj6qo gmail-ajU" style="margin:2px 0px 0px;font-size:12.8px"><div id="gmail-:3em" class="gmail-ajR" tabindex="0"><img class="gmail-ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif" style="opacity: 0.3;"></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 30, 2017 at 7:44 AM, Ali Ghanbari <span dir="ltr"><<a href="mailto:microdeniz@gmail.com" target="_blank">microdeniz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>I noticed that a bunch of methods in JDK library have more than one head node in their exceptional unit graphs. With a more careful examination, I noticed that in all cases the methods are in one of this form:</div><div><br></div><div><div>static {</div><div> try {</div><div> I1; ...; In;</div><div> } catch (...) {</div><div> J1; ...; Jn;</div><div> }</div><div>}</div></div><div><br></div><div>or</div><div><br></div><div>modifiers return-type method-name() {</div><div> try {</div><div> I1; ...; In;</div><div> } catch (...) {</div><div> J1; ...; Jn;</div><div> }</div><div>}</div><div><br></div><div>or</div><div><br></div><div><div>modifiers return-type method-name() throws-clause {</div><div> try {</div><div> I1; ...; In;</div><div> } catch (...) {</div><div> J1; ...; Jn;</div><div> }</div><div>}</div></div><div><br></div><div>In which the heads become the instructions I1 and J1!</div><div><br></div><div>Does that mean that the methods have multiple entries? Is that a bug?</div><div><br></div><div>Can anyone explain, please?</div><div><br></div><div>Thank you.</div><div>PS: Similarly, once you construct exceptional unit graph for a method, many of tails are not actually tails (e.g. when you throw an exception and immediately catch it in a try-catch-block).</div></div>
<br></blockquote></div></div></div>