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

[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



-- 
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