[Soot-list] Problems with nested try..catch..finally?
Eric Bodden
bodden at st.informatik.tu-darmstadt.de
Fri Oct 9 07:15:02 EDT 2009
Hi Attila.
> Are there any known issues and limitations with regards to Exception
> handling?
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
problem.
> 2. Is it possible to skip or replace the call of
> soot.coffi.CFG.eliminateJsrRets()?
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.
Eric
--
Eric Bodden
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
mailing list