[Soot-list] CFG and exception analysis

[John Jorgensen]

>>>>> "irem" == Irem Aktug <irem at nada.kth.se> writes:
    irem> I have a code that looks something like this:


    irem> try { Scheduler.schedule(); }

    irem> catch (SimulationException e){ }

    .
    .
    .
    irem> Yet, in my flow graph it looks like invokestatic
    irem> may throw a Throwable. And I get an edge as if the
    irem> exception thrown by invokestatic (and not the called
    irem> method) is handled by the handler above. Yet
    irem> SimulationException is an application defined
    irem> exception.

You probably already know this, but the existing exception
analyses (unless somebody has added something since 2003), are
strictly intraprocedural.  So they have to assume that any called
method has the potential to call any Throwable (potentially
Throwables which have yet to be declared).

    irem> My objective is to seperate between exceptions thrown
    irem> by the invocation instruction and the invoked method
    irem> itself. So that in my graph there will be two edges
    irem> ending in exceptions, only one labeled with the called
    irem> method. So I want to make sure that this Throwable
    irem> exceptional destination is indeed for the invocation
    irem> instruction and not the invoked method. Is this the
    irem> case?

Indeed, this Throwable is for the invoked method.  Take a
look at /src/soot/toolkits/exceptions/UnitThrowAnalysis.java
(which is essentially just a big switch statemernt):

   public void caseStaticInvokeInst(StaticInvokeInst i) {
       result = result.add(mgr.INITIALIZATION_ERRORS);
       result = result.add(mightThrow(i.getMethod()));
   }

The existing UnitThrowAnalysis.mightThrow(SootMethod) just
returns (Throwable), no matter what argument it is passed.  It
sounds like you're trying to replace it with something
interprocedural.  Ideally, you should be able to do this by
adding a new implementation of the ThrowAnalysis interface (maybe
even a subclass of UnitThrowAnalysis which just overrides the
mightThrow(SootMethod) method).

    irem> My first question is a little off limits... I am just
    irem> wondering... Take an instruction (not a method call of
    irem> course) that may throw for instance
    irem> NullPointerException. And assume that there is an
    irem> application defined exception class that inherits from
    irem> this exception type. Shouldn't the control flow graph
    irem> have an exceptional destination for
    irem> (NullPointerException)-(UserDefinedException)? This
    irem> kind of analysis I can guess would take time. But I am
    irem> asking nonetheless.

First of all, in your example of a non-method-call which might
throw NullPointerException, I believe the existing code (when you
specify UnitThrowAnalysis rather than PedanticThrowAnalysys) will
report that the unit can throw

  NullPointerException

not

  (NullPointerException)

The former is ThrowableSet.toAbbreviatedString()'s printable
representation for a single soot.RefType (only
NullPointerException itself), the latter for a soot.AnySubType
(NullPointerException and its subclasses).  So
UserDefinedException is not included in the ThrowableSet for your
example.

As an aside to your aside, in the original exceptional analysis
code (again, I'm not certain it hasn't been improved since I
touched it last) the "-" terms in ThrowableSets arise only as a
result of removing caught exceptions. If, for example, you're
analyzing

    try {
      m();  // A
    } catch (ArrayIndexOutOfBoundsException e) {
       i = -1;  // B
    } catch (Throwable t) {
       i = -2;  // C
    }

The ExceptionDest edge from A to C will be labeled with
(Throwable)-(ArrayIndexOutOfBoundsException) because the
ExceptionalGraph constructors remove the exceptions caught by B
from the set of exceptions that may be caught by C.

(If I remember correctly, the technical report includes a
discussion of the difficulties with representing "holes" in type
hierarcharies, which is the reason ThrowableSet lacks a general
"remove" operation).

There is, incidentally, a barrier to using "-" more broadly to
abbreviate ThrowableSet descriptions as you suggest. Say you're
analyzing a program which defines MyException, with subclasses
MyExceptionA, MyExceptionB, MyExceptionC, ...  through to
MyExceptionZ, and you've added an analysis capable of determining
that some invoke Unit, call it unitA, can throw any of these
exceptions except MyExceptionQ.

If only to save screen space when producing visualizations of
the control flow graph, you'd like to depict the ThrowableSet
associated with unitA as

    (MyException)-MyExceptionA-MyException

(with the second "subtraction" indicating that MyException
itself cannot be thrown, only its subclasses).

I think that would be correct, but it is potentially more
conservative than necessary, since even if the code you are
analyzing is later linked to new classes which define new
subtypes of MyException---say, MyExceptionA1 through
MyExceptionA9---unitA will still only have the potential to throw

    MyExceptionA+MyExceptionB+ ...+MyExceptionP+MyExceptionR+ ...+MyExceptionZ

while the ThrowableSet

    (MyException)-MyExceptionA-MyException

would imply it could also throw MyExceptionA1 through MyExceptionA10.