[Soot-list] ExceptionalUnitGraph Multiple Heads! Is that a bug?

John Jorgensen jorgensen.john at gmail.com
Fri Jun 30 12:08:43 EDT 2017


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 the exceptions Tech Report
<http://www.sable.mcgill.ca/publications/techreports/sable-tr-2003-3.pdf>).
I'll grant you it might be a bug in the sense of being a poor design
decision.

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.

In the code

static {
    try {
       I1; ...; In;
     } catch (...) {
       J1; ...; Jn;
     }
}

imagine that l1 is the instruction "int 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,

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.

Again, see section 2.4 of the technical report for a discussion of just
what nodes and edges of the CFG mean.

On Fri, Jun 30, 2017 at 7:44 AM, Ali Ghanbari <microdeniz at gmail.com> wrote:

> Hello,
>
> 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:
>
> static {
>     try {
>        I1; ...; In;
>      } catch (...) {
>        J1; ...; Jn;
>      }
> }
>
> or
>
> modifiers return-type method-name() {
>     try {
>        I1; ...; In;
>      } catch (...) {
>        J1; ...; Jn;
>      }
> }
>
> or
>
> modifiers return-type method-name() throws-clause  {
>     try {
>        I1; ...; In;
>      } catch (...) {
>        J1; ...; Jn;
>      }
> }
>
> In which the heads become the instructions I1 and J1!
>
> Does that mean that the methods have multiple entries? Is that a bug?
>
> Can anyone explain, please?
>
> Thank you.
> 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).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20170630/633375a7/attachment.html>


More information about the Soot-list mailing list