[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