[Soot-list] Switching the default throws analysis?

John Jorgensen jorgnsn at cs.uregina.ca
Fri Aug 3 11:39:56 EDT 2012


There's one non-obvious potential drawback to switching from
"pedantic throws analysis" to "unit throw analysis" as Soot's
default: it might mean that Soot's default settings would have
the potential to generate bytecode which fails verification.

The bytecode verifiers implemented by JVMs may well be more
sophisticated now than they were in 2003 when I re-implemented
Soot's exception analysis, but back then, I found out the hard
way that bytecode verifiers were assuming that all instructions
within a try block have the potential to throw exceptions to its
catch handler.  As a result, pruning unrealizable exceptional
control flow from the CFGs used for some Soot optimzations could
generate code that the verifiers rejected.

For more detail, see sections 2.6 and 3.4 (especially 3.4.3 and
3.4.4) of Sable Technical Report 2003-3, "Improving the precision
and correctness of exception analysis in Soot".

I added the TrapTightener transformer (jb.tt) as a kludge to keep
the JVMs of the day from rejecting any of the bytecode Soot
generated for the benchmark suite we were using in 2003.
TrapTightener effectively shrinks try{} blocks to exclude the
instructions at the beginning and at the end of the block which
cannot throw an exception that the corresponding catch() handler
catches.  That sufficed to keep soot from generating unverifiable
code from our benchmark suite of the day, but it does not
eliminate the theoretical possibility of generating unverifiable
code.  Again, for more detail, see the technical report.



>>>>> "eric.bodden" == Eric Bodden <eric.bodden at ec-spride.de> writes:

    eric.bodden> Hi all.  Soot's default throw analysis is the
    eric.bodden> "pedantic throws analysis", which assumes that
    eric.bodden> every statement can throw any sort of
    eric.bodden> exception. This has mostly historic reasons:
    eric.bodden> There is a method Thread.stop() that used to
    eric.bodden> kill a thread, causing apparently all sorts of
    eric.bodden> exceptions to be thrown asynchronously. IMHO
    eric.bodden> this is now outdated, as Thread.stop() is
    eric.bodden> deprecated. In fact, I am not sure if VMs still
    eric.bodden> allow this method to be called. I hence suggest
    eric.bodden> to switch Soot's default to UnitThrowsAnalysis,
    eric.bodden> which is a much more precise (and sensible)
    eric.bodden> default to have.

    eric.bodden> Any objections?

    eric.bodden> Cheers, Eric

    eric.bodden> -- Eric Bodden, Ph.D., http://bodden.de/ Head of
    eric.bodden> Secure Software Engineering Group at EC SPRIDE
    eric.bodden> Tel: +49 6151 16-75422 Fax: +49 6151 16-72051
    eric.bodden> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
    eric.bodden> _______________________________________________
    eric.bodden> Soot-list mailing list Soot-list at sable.mcgill.ca
    eric.bodden> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list


More information about the Soot-list mailing list