[Soot-list] unreachable code in jimple files?

[Martin Schäf]

I have a new opinion and this might also be interesting for another email
thread that talks about detecting finally blocks:
In
>             21   135   170   Class java/lang/Throwable
>             21   135   179   any
Is it possible that the "catch" is the first line, and the finally the the
second? Because, as finally is executed anyway, it actually does also catch
stuff that is not "Throwable" (even though you have to switch off the
bytecode verifier for that).

So without any evidence to support this claim: if finally blocks and up as
"any"  in the exception table, this could be super useful to detect them,
and would be a nice to have in Jimple (which apparently turns them into
Throwable).

On the other hand, how would you pitch a problem like this to the JDK folks
/ how do you reach them?




On Tue, Sep 2, 2014 at 4:00 AM, Bodden, Eric <eric.bodden at sit.fraunhofer.de>
wrote:

> Hi Martin.
>
> > The problem is already in the bytecode. The exception table says
> something like
> >             21   135   170   Class java/lang/Throwable
> >             21   135   179   any
> > Is there a good reason why the second line is not useless?
>
> To me this seems like a compiler inaccuracy. Technically it's not really a
> bug because at runtime it doe the right thing, although the second trap is,
> in fact, useless. At analysis time, however, it causes the problems you
> mention.
>
> I am not sure why they compile the code by this. It might be worthwhile
> raising a bug against the JDK.
>
> Cheers,
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20140902/c32d36bc/attachment.html