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

[Eric Bodden]

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