[Soot-list] Switching the default throws analysis?

[Eric Bodden]

Hi John.

Thanks a lot for the detailed writeup. It's good to have this on
record... My suggestion would be to keep things as they are right now
for the time being, and if we expect difficulties then we can still
roll back. Another possibility would be to use the
PedanticThrowsAnalysis during Jimplification but to still keep
UnitThrowsAnalysis as the default. (because in jtp "pedantic" likely
not what users want)

What do you think?
Eric

On 3 August 2012 17:39, John Jorgensen <jorgnsn at cs.uregina.ca> wrote:
> 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



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt