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

Tillmann tirunkel at informatik.uni-bremen.de
Thu Jan 19 11:05:10 EST 2012


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


More information about the Soot-list mailing list