[Soot-list] Problems with nested try..catch..finally?
at.bartha at gmail.com
Fri Oct 9 10:01:31 EDT 2009
I will try isolate the byte code that causes this problem.
From: eric.bodden at googlemail.com [mailto:eric.bodden at googlemail.com] On
Behalf Of Eric Bodden
Sent: Freitag, 9. Oktober 2009 13:15
To: Attila Bartha
Cc: soot-list at sable.mcgill.ca
Subject: [?? Probable Spam] Re: [Soot-list] Problems with nested
> Are there any known issues and limitations with regards to Exception
Not that I am aware of. Coffi has been one of the most stable
components of Soot for as long as I can tell. It be really helpful to
see the bytecode that causes this problem. Are you sure that it's
legal bytecode, i.e., can you run it?
> 1. Is there a quick fix for this problem?
I could add a check to the CFG class so that the constructor does not
execute eliminateJsrRets() if there are no JSRs in the first place. (I
am 99% sure that your code contains no JSRs, they have become very
rare.) However, that would only cure the symptoms, not fix the
> 2. Is it possible to skip or replace the call of
Well, yes, see above, but there's no command line option for skipping it.
> 3. Why does dava not generate finally blocks? It generates another
> try..catch instead.
Java uses certain heuristics to try to identify source-code patterns
like "finally" in bytecode. Heuristics can fail. Having said that, I
am not even sure if there is a heuristic for "finally" in dava. In any
case, dava should hopefully generate at least correct code, even if
that ocde is sometimes far from the original.
Software Technology Group, Technische Universität Darmstadt, Germany
Tel: +49 6151 16-5478 Fax: +49 6151 16-5410
Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt
More information about the Soot-list