[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