Is it ok for me to forward this to the asm list? Because I think if
there is really a constant pool entry that is wrong, then it is probably
a bug in asm, since we do not really set constant pool entries directly.
bye Jcohen
On 12.07.2016 05:25, NETEASE wrote:
hello,I uploaded the stack trace and javap of the class to MediaFire,
you can download them from:
http://www.mediafire.com/download/c8f942tf77jvh66/stack-trace.txt
http://www.mediafire.com/download/39tv7qkwm9b1cpt/javap.txt
besides, if I enable @CompileStatic then the problem is gone, please
help me to figure out what's wrong.
Many thanks~
At 2016-07-11 04:08:47, "Jochen Theodorou" <[email protected]> wrote:
On 10.07.2016 16:30, NETEASE wrote:
Hi, the following stack trace is thrown when I upgraded groovy(indy)
from 2.3.11 to 2.4.7 and replaced groovy-eclipse-compiler
with GMavenPlus which supports INDY feature.
Caused by: java.lang.VerifyError: (class:
com/xxx/yyydaemon/ScheduleTransferChannelTask, method: executeTask
signature:
(Lcom/xxx/yyy/client/executor/simple/processor/SimpleJobContext;)V)
Illegal type in constant pool
the output of javap -v ScheduleTransferChannelTask is the following:
Classfile
/home/wangyin.wy/com/xxx/yyydaemon/ScheduleTransferChannelTask.class
Last modified 2016-7-8; size 10220 bytes
MD5 checksum f0262d363ad22b0e64e8e3e59d344cbc
Compiled from "ScheduleTransferChannelTask.groovy"
Has anyone seen the same issue and share how to solve it?
Thanks~
I think without looking at the actual bytecode there is no chance to
tell what the problem is. "Illegal type in constant pool" is a very
generic error, and it could mean anything from using the wrong invoke to
a wrong ldc somewhere...
bye Jochen
