[Soot-list] try catch transformation question

[Heejong Lee]

Hi, Eric.
Sorry but I didn't catch your word exactly.
IMHO, this looks irrelevant with insufficient type information.
Exception trap table is already in compiled byte code, therefore Soot
is just needed to transform it to Jimple IL. The unsound optimization
like Soot did in this case should never happen cause it breaks program
integrity, should it? If Soot cannot figure out which exceptions
exactly are caught where, the two catch statement must remain.

Please let me know where my misunderstanding comes from.
Thanks always.

Regards,

- Heejong

Ps. We couldn't give up allow-phantom-refs option since we're making a
static bug finder. In many cases, the analyzer doesn't know complete
library classes.

On Wednesday, June 15, 2011, Eric Bodden
<bodden at st.informatik.tu-darmstadt.de> wrote:
> Heejong, this has to do with the fact that you used allow-phantom-refs.
>
> Because you do, Soot the fact that it does not know about the types
> IOException and Exception and about their type hierarchy. In
> particular, it ignores the fact that it cannot figure out which
> exceptions exactly are caught where.
>
> The solution is to not use the allow-phantom-refs option but instead
> to include rt.jar or classes.jar (OSX) on Soot's classpath.
>
> Eric
>
> On 14 June 2011 18:43, Heejong Lee <heejong at gmail.com> wrote:
>> I use a "-allow-phantom-refs -f jimple" option and a byte-code input
>> (soot trunk build).
>> Actually, the sample code always produce just 'Exception' not
>> 'IOException' so Soot
>> should not omit 'Exception' catch statements. Strange.
>>
>> Regards,
>>
>> - Heejong
>>
>> On Tue, Jun 14, 2011 at 11:56 PM, Eric Bodden
>> <bodden at st.informatik.tu-darmstadt.de> wrote:
>>> Hello.
>>>
>>>> Anybody explain why this happen?
>>>
>>> Well, it depends on which optimizations you have enabled. It *may* be
>>> the case that Soot "sees" that your method can never throw an
>>> Exception when called with parameter value 1 and therefore it *may*
>>> have optimized away the trap. This would surprise me, though.
>>>
>>> What is your command line? Are you analyzing source code or bytecode?
>>>
>>> Eric
>>> --
>>> Dr. Eric Bodden, http://bodden.de/
>>> Principal Investigator in Secure Services at CASED
>>> Coordinator of the CASED Advisory Board of Study Affairs
>>> PostDoc at Software Technology Group, Technische Universität Darmstadt
>>> Tel: +49 6151 16-5478    Fax: +49 6151 16-5410
>>> Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt
>>>
>>
>>
>>
>> --
>> Heejong Lee
>>
>> Associate Research Engineer
>> Program Analysis Division
>> Fasoo.com, Inc. (www.spa-arrow.com)
>>
>
>
>
> --
> Dr. Eric Bodden, http://bodden.de/
> Principal Investigator in Secure Services at CASED
> Coordinator of the CASED Advisory Board of Study Affairs
> PostDoc at Software Technology Group, Technische Universität Darmstadt
> Tel: +49 6151 16-5478    Fax: +49 6151 16-5410
> Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt
>


-- 
Heejong Lee

Associate Research Engineer
Program Analysis Division
Fasoo.com, Inc. (www.spa-arrow.com)