[Soot-list] interface invoke expression for non-interface type

[Tillmann]

Thanks Eric for your investigations.

I've reported that and it's led under Bug #122.

For my concerns i can easily work-around this problem.

Tillmann

Am 20.01.2012 11:56, schrieb Eric Bodden:
> Hmm, I can confirm this is a bug. It's a nested JSR, that for some
> reason does not get eliminated. As I said, I guess this bug does not
> get triggered often because this is really odd code. I wonder what
> compiler the lucene folks are using...
>
> I may look into this some more when I have more time, but not today.
> Tillmann, could you open a bug reprot and attach the class file to it?
> Thanks
>
> Eric
>
> On 19 January 2012 17:32, Eric Bodden<eric.bodden at ec-spride.de>  wrote:
>> Tillmann, could you send me the .class file by email? Then I will try
>> to reproduce this here.
>>
>> Eric
>>
>> On 19 January 2012 17:05, Tillmann<tirunkel at informatik.uni-bremen.de>  wrote:
>>>>> I've checked this with the stable v2.4. The trunk-version seems to be
>>>>> more
>>>>> forgiving about class resolving. Without the allow-phantom-refs-option
>>>>> soot2.4 exits with an Exception that indicates the missing Class (in my
>>>>> case
>>>>> the Authentication of the Spring Framework) If i add the relevant parts
>>>>> of
>>>>> the Spring-Framework, the classloading seems to be okay. So i switched
>>>>> back
>>>>> to the trunk-version of soot but now during the CHA-Transformation
>>>>> following
>>>>> occurs:
>>>>>
>>>>> Exception in thread "main" java.lang.RuntimeException: Unrecognized
>>>>> bytecode
>>>>> instruction: 168
>>>>>     at soot.coffi.CFG.generateJimple(CFG.java:4637)
>>>>>     at soot.coffi.CFG.jimplify(CFG.java:1267)
>>>>>
>>>>> with 2.4 the same occurs:
>>>>>
>>>>> Exception in thread "main" java.lang.RuntimeException: Unrecognized
>>>>> bytecode
>>>>> instruction: 168
>>>>>     at soot.coffi.CFG.generateJimple(CFG.java:4644)
>>>>>     at soot.coffi.CFG.jimplify(CFG.java:1263)
>>>>>     at soot.coffi.CFG.jimplify(CFG.java:951)
>>>>>
>>>>> So i will take a closer look at the bytecode. I'll keep you current.
>>>> This is odd for two reasons: First, 168 is a JSR bytecode, which has
>>>> been deprecated for ages. Second, though, Soot usually should handle
>>>> JSRs correctly, converting them into other equivalent bytecodes.
>>>> Having said that, I am not sure when someone last loaded a class file
>>>> with a JSR into Soot...
>>>>
>>>> Eric
>>>
>>> the problem occurs when parsing the following Instruction (in
>>> org.apache.lucene.store.NativeFSLock.class - part of apache's lucene-core
>>> library)
>>>
>>> 73: jsr[73]    79
>>>
>>> by generateJimple(...) in CFG:2924
>>>
>>> in which step the jsr-handling takes place?
>>>
>>> Regards
>>>
>>> Tillmann
>>>
>>> surrounding bytecode:
>>>
>>> // Method descriptor #80 ()V
>>>   // Stack: 4, Locals: 9
>>>   public synchronized void release() throws java.io.IOException;
>>>       0  aload_0 [this]
>>>       1  invokespecial org.apache.lucene.store.NativeFSLock.lockExists() :
>>> boolean [7]
>>>       4  ifeq 167
>>>       7  aload_0 [this]
>>>       8  getfield org.apache.lucene.store.NativeFSLock.lock :
>>> java.nio.channels.FileLock [6]
>>>      11  invokevirtual java.nio.channels.FileLock.release() : void [35]
>>>      14  jsr 26
>>>      17  goto 127
>>>      20  astore_1
>>>      21  jsr 26
>>>      24  aload_1
>>>      25  athrow
>>>      26  astore_2
>>>      27  aload_0 [this]
>>>      28  aconst_null
>>>      29  putfield org.apache.lucene.store.NativeFSLock.lock :
>>> java.nio.channels.FileLock [6]
>>>      32  aload_0 [this]
>>>      33  getfield org.apache.lucene.store.NativeFSLock.channel :
>>> java.nio.channels.FileChannel [30]
>>>      36  invokevirtual java.nio.channels.FileChannel.close() : void [32]
>>>      39  jsr 51
>>>      42  goto 125
>>>      45  astore_3
>>>      46  jsr 51
>>>      49  aload_3
>>>      50  athrow
>>>      51  astore 4
>>>      53  aload_0 [this]
>>>      54  aconst_null
>>>      55  putfield org.apache.lucene.store.NativeFSLock.channel :
>>> java.nio.channels.FileChannel [30]
>>>      58  aload_0 [this]
>>>      59  getfield org.apache.lucene.store.NativeFSLock.f :
>>> java.io.RandomAccessFile [27]
>>>      62  invokevirtual java.io.RandomAccessFile.close() : void [33]
>>>      65  jsr 79
>>>      68  goto 123
>>>      71  astore 5
>>>      73  jsr 79 //<-- BAD LINE!
>>>      76  aload 5
>>>      78  athrow
>>>      79  astore 6
>>>      81  aload_0 [this]
>>>      82  aconst_null
>>>      83  putfield org.apache.lucene.store.NativeFSLock.f :
>>> java.io.RandomAccessFile [27]
>>>      86  getstatic org.apache.lucene.store.NativeFSLock.LOCK_HELD :
>>> java.util.HashSet [21]
>>> ...
>>
>>
>> --
>> Eric Bodden, Ph.D., http://bodden.de/
>> Head of Secure Software Engineering Group at EC SPRIDE
>> Principal Investigator in Secure Services at CASED
>> Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
>> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>
>