[Soot-list] Problems with nested try..catch..finally?

[Attila Bartha]

Thank you!
I will try isolate the byte code that causes this problem.

Attila

-----Original Message-----
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
try..catch..finally?

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