[Soot-list] exception handler lookup

[John Jorgensen]

>>>>> "gdennis" == Greg Dennis <gdennis at mit.edu> writes:

    gdennis> The key documentation that seems to be lacking in
    gdennis> the API is any specification as to the order of the
    gdennis> exception destinations in the collection returned by
    gdennis> getExceptionDests. 

I'm not sure that I'm understanding your question correctly,
since the intention of the Exceptional*Graph classes
is that the order of the returned destinations shouldn't matter.

    gdennis> For instance, it is not clear from the API that the
    gdennis> destination for one trap will always precede the
    gdennis> destination for an enclosing trap.

Again, I'm not certain what you're getting at, since the set of
destinations returned for a given unit already takes the
nesting of handlers into account. Let's try to make things clear
with an example:

  public static int m1(int i, Object o) {
    int r = 100;                
    try {
      r = 30;
      try {
      int temp = o.hashCode(); // A
      r = r / temp;            // B
      } catch (ArithmeticException ae) {
      r = 0;                   // C
      }
    } catch (RuntimeException re) {
      r = -1;                  // D
    }
    return r;
  }

If you generate an ExceptionalUnitGraph for this method and ask
for the destinations corresponding to unit A:

  g.getExceptionDests(A) 

the collection returned will contain three ExceptionDest objects
(returned in arbitrary order):

  - one leading to Trap C, whose catchableAs() will match
    ArithmeticException (because the CFG analysis is only
    intraprocedural, it has to assume that hashCode() might throw
    an ArithmeticException).

  - one leading to Trap D, whose catchableAs() will match
    RuntimeException and all its subtypes, except for
    ArithmeticException.

  - one escaping the method (with null as its Trap), whose
    catchableAs() will match all Throwable types except for
    RuntimeException and its subtypes

Since the iterator returns the destinations in arbitrary order,
it's true that you don't know whether the destination object
corresponding to the inner Trap C will precede or follow that
corresponding to the outer Trap D. But I don't understand why you
care; nesting only matters because it indicates which handler
gets first crack at an exception when more than one handler might
match the exception's type. The analysis which produces the
destinations takes nesting into account to determine that the
ArithmeticException is caught by C rather than D, and the
catchableAs() method of the destinations indicates that.

(I'll try to attach a PDF file of the jimple graph I produced for
this example, using the commands

  java -Djunk=junk -mx412m -classpath \
    /nobackup/soot/trunk/classes:/nobackup/soot/trunk/testclasses:/nobackup/jasmin/trunk/classes:/nobackup/soot/polyglot.jar:/nobackup/soot/jedd-runtime.jar:/usr/local/pkgs/junit-3.7/junit.jar \
    soot.tools.CFGViewer --soot-classpath \
    .:.:/usr/local/pkgs/java/jre/lib/rt.jar:/usr/local/pkgs/java/jre/lib/jce.jar:/nobackup/soot/trunk/classes:/nobackup/soot/trunk/testclasses:/nobackup/jasmin/trunk/classes:/nobackup/soot/polyglot.jar \
    -f none --graph=ExceptionalUnitGraph --throw-analysis unit \
    --show-exception-dests --omit-excepting-unit-edges ExceptionEg

  dot -Gmargin=0.013 -Gsize="7.5,10" -Tps2 \
    "int m1(int,java.lang.Object).dot" | ps2pdf14 - > "m1.pdf"

I'd suggest cooking up a few small examples of your own, and
generating visualizations of the corresponding graphs.  By
default, the gray arcs correspond to ExceptionDests, the black
arcs to regular control flow edges, and the red arcs to
exceptional control flow edges.)

    gdennis> Also, some of the exception destinations of a unit
    gdennis> included in the returned collection are actually for
    gdennis> exceptions thrown by successor units. 

If this occurs, you've exposed a bug in the Exceptional*Graph
classes, so I would appreciate it if you can provide an example
method which generates such a graph.

Maybe your impression that the Exception destinations for a unit
include the exceptions thrown by successor units is due to the
conservative defaults used to generate exceptional graphs.  If
you do not specify "--throw-analysis unit", on soot's command
line (or set the ThrowAnalysis explicitly in the
ExceptionalUnitGraph constructor, if you're calling it
explicitly), the graphs will be constructed with the
PedanticThrowAnalysis, which simply assumes that all units have
the potential to throw all exception types (which, strictly
speaking, they do, since it's always conceivable that some other
thread will call java.lang.Thread.stop() to deliver an arbitrary
Throwable, whatever the instruction being executed in the method
being examined).  For instance, when you use the default
PedanticThrowAnalysis instead of UnitThrowAnalysis for our
example above, there is an ExceptionDest from "r = 30" to Trap D,
even though the assignment cannot generate a RuntimeException in
the normal course of events.

    gdennis> Does the collection's iterator always return the
    gdennis> destinations for exceptions generated by the unit in
    gdennis> question before the destinations for succesor units?

If the collection's iterator returns any destinations for
exceptions that are not generated by the unit in question, then
the exceptional control flow analysis code is broken, and I would
like to see the method that triggers the bug.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: m1.pdf
Type: application/pdf
Size: 11292 bytes
Desc: PDF of exception destinations and CFG
Url : http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20060323/1de2aa2d/m1.pdf