March 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JASSIST-79) Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | goto points to invalid instruction

by Martin Burger (JIRA)

Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | goto points to invalid instruction ---------------------------------------------------------------------------------------------------------------------------------------------- Key: JASSIST-79 URL: https://jira.jboss.org/jira/browse/JASSIST-79 Project: Javassist Issue Type: Bug Affects Versions: 3.10.0.GA Environment: $ java -version java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode) Reporter: Martin Burger Assignee: Shigeru Chiba I instrument method calls in a class called org.mozilla.javascript.Parser. If I run (or, load) this class, a java.lang.VerifyError will be thrown: Exception in thread "main" java.lang.VerifyError: (class: org/mozilla/javascript/Parser, method: statementHelper signature: (Lorg/mozilla/javascript/TokenStream;)Ljava/lang/Object;) Illegal target of jump or branch It seems Javassist introduces a defective goto statement at position 3200 in method statementHelper: 3200: goto -29495 Obviously, offset -29495 is an invalid opcode address. The corresponding Java code (excerpt): switch(tt) { case TokenStream.IF: { skipsemi = true; sourceAdd((char)ts.IF); int lineno = ts.getLineno(); Object cond = condition(ts); sourceAdd((char)ts.LC); sourceAdd((char)ts.EOL); Object ifTrue = statement(ts); Object ifFalse = null; if (ts.matchToken(ts.ELSE)) { sourceAdd((char)ts.RC); sourceAdd((char)ts.ELSE); sourceAdd((char)ts.LC); sourceAdd((char)ts.EOL); ifFalse = statement(ts); } sourceAdd((char)ts.RC); sourceAdd((char)ts.EOL); pn = nf.createIf(cond, ifTrue, ifFalse, lineno); break; } case TokenStream.SWITCH: { I think the break statement is related to this defect. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
8
0 / 0

[JBoss JIRA] Created: (JASSIST-67) Strange Exception: Register x contains wrong type

by kobe valiant (JIRA)

Strange Exception: Register x contains wrong type ------------------------------------------------- Key: JASSIST-67 URL: https://jira.jboss.org/jira/browse/JASSIST-67 Project: Javassist Issue Type: Bug Affects Versions: 3.8.1.GA Environment: windowsXP Reporter: kobe valiant Assignee: Shigeru Chiba Priority: Blocker ClassPool pool = new ClassPool(true); CtClass ctc = pool.makeClass("my.Clazz"); StringBuilder sb = new StringBuilder("public void test() {"); for (int i = 0; i < 1000; i++) { sb.append("for(int i=0; i<10; i++) {}"); // line 1 // sb.append("for(int i=0; i<10; i++) {int j=i;}"); // line 2 } sb.append("}"); ctc.addMethod(CtNewMethod.make(sb.toString(), ctc)); ctc.toClass().newInstance(); the code above will throw an exception: Exception in thread "main" java.lang.VerifyError: (class: my/Clazz, method: test signature: ()V) Register 0 contains wrong type But if you comment the line 1 and uncomment the line 2, there will no exception at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JASSIST-70) instrumenting a constructor with insertAfter() and asFinally=true

by Shigeru Chiba (JIRA)

instrumenting a constructor with insertAfter() and asFinally=true ----------------------------------------------------------------- Key: JASSIST-70 URL: https://jira.jboss.org/jira/browse/JASSIST-70 Project: Javassist Issue Type: Bug Reporter: Shigeru Chiba Assignee: Shigeru Chiba (reported by Patrice Bouillet) Instrumenting a Constructor with the insertAfter method and 'asFinally' set to true leads to a corrupt constructor. This is due to surrounding the this() and super() calls which cannot be done. Solution: I think you already know the solution, because the correct behaviour is already done for the addCatch method, so for the insertAfter method in CtBehaviour I just modified the line according to the addCatch: if (asFinally) { ca.getExceptionTable().add(getStartPosOfBody(ca), gapPos, gapPos, 0); } With this modification, the instrumentation works as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JASSIST-71) Array access replacement generates invalid bytecode when padding is required

by Jason T. Greene (JIRA)

Array access replacement generates invalid bytecode when padding is required ---------------------------------------------------------------------------- Key: JASSIST-71 URL: https://jira.jboss.org/jira/browse/JASSIST-71 Project: Javassist Issue Type: Bug Reporter: Jason T. Greene Assignee: Shigeru Chiba When an array access instruction is replaced before a switch instruction, and padding is added to align the switch, the array instruction remains, which is invalid: public void test(); Code: Stack=2, Locals=2, Args_size=1 0: aconst_null 1: astore_1 2: invokestatic #17; //Method $SWITCH_TABLE$RULE_TYPE:()[I 5: aload_1 6: invokevirtual #20; //Method RULE_TYPE.ordinal:()I 9: invokestatic #67; //Method arrayReadInt:(Ljava/lang/Object;I)I 12: nop 13: iaload <=========================== INVALID!!!!!!!!!!!! 14: tableswitch{ //1 to 1 1: 32; default: 32 } 32: return This is typically caught by the bytecode verifier java.lang.VerifyError: (class: com/lm/dataModel/rules/StatusRule, method: propagateFromHereOnUpTree signature: (Lcom/lm/dataModel/ANode;Lcom/lm/dataModel/ANode$Source;Lcom/lm/dataModel/ANode$StatusValue;)Z) Unable to pop operand off an empty stack at com.lm.dataModel.ANode.setStatusValueWithPropagation(ANode.java:301) at com.lm.seem.StatusTableModel.setValueAt(StatusTableModel.java:133) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JASSIST-77) ClassFile.renameClass(s) is not processing the LocalVariableAttributes

by Adrian Brock (JIRA)

ClassFile.renameClass(s) is not processing the LocalVariableAttributes ---------------------------------------------------------------------- Key: JASSIST-77 URL: https://jira.jboss.org/jira/browse/JASSIST-77 Project: Javassist Issue Type: Bug Reporter: Adrian Brock Assignee: Shigeru Chiba ClassFile.renameClass(s) is not changing the descriptor indexes for LocalVariableAttributes. This means the types of local variables are not getting updated. See the forum thread for an example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JASSIST-75) SerializedProxy should use TCCL in readResolve

by Ales Justin (JIRA)

SerializedProxy should use TCCL in readResolve ---------------------------------------------- Key: JASSIST-75 URL: https://jira.jboss.org/jira/browse/JASSIST-75 Project: Javassist Issue Type: Bug Reporter: Ales Justin Assignee: Shigeru Chiba Fix For: 3.10.0.GA When loading classes in SerializedProxy::readResolve we should use TCCL instaed of caller CL. e.g. ClassLoader cl = Thread.currentThread().getContextClassLoader(); cl.loadClass(name); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

3
7
0 / 0

[JBoss JIRA] Created: (JASSIST-72) Instrumenting write access using CodeConverter.replaceArrayAccess(...) causes VerifyError (Unable to pop operand off an empty stack) - buggy aastore

by Martin Burger (JIRA)

Instrumenting write access using CodeConverter.replaceArrayAccess(...) causes VerifyError (Unable to pop operand off an empty stack) - buggy aastore ---------------------------------------------------------------------------------------------------------------------------------------------------- Key: JASSIST-72 URL: https://jira.jboss.org/jira/browse/JASSIST-72 Project: Javassist Issue Type: Bug Environment: javassist 3.9.0.GA Reporter: Martin Burger Assignee: Shigeru Chiba I use Javassist to instrument class files in order to catch some runtime information. Basically, I insert probes to get information about method calls, field accesses, and so on. This includes access to arrays. Unfortunately, when I instrument array accesses using CodeConverter.replaceArrayAccess(...) the Java verifier throws an exception while loading the changed method: Unable to pop operand off an empty stack. Instrumenting array accesses is one instrumentation of many. If I disable instrumentation of array accesses, the instrumented program will run and I will get runtime information about method calls etc. As soon as I enable the instrumentation of arrays, the byte code created by javassist causes the java.lang.VerifyError mentioned above. The buggy byte code instruction seems to be: 7016: anewarray #51; //class java/lang/Object 7019: dup 7020: iconst_0 7021: iload_1 7022: bipush 56 7024: if_icmpne 7036 7027: ldc_w #5369; //String 8 7030: nop 7031: nop 7032: nop 7033: goto 7042 7036: ldc_w #5371; //String 9 7039: nop 7040: nop 7041: nop 7042: invokestatic #5373; 7045: nop 7046: aastore <-- causes VerifyError At least when executing aastore the stack is empty already. The original source code: if (base == 8 && c >= '8') { Object[] errArgs = { c == '8' ? "8" : "9" }; reportCurrentLineWarning( "msg.bad.octal.literal", errArgs); base = 10; } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JASSIST-80) Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | invalid instruction

by Martin Burger (JIRA)

Editing MethodCall produces incorrect byte code | java.lang.VerifyError: Illegal target of jump or branch | invalid instruction ------------------------------------------------------------------------------------------------------------------------------- Key: JASSIST-80 URL: https://jira.jboss.org/jira/browse/JASSIST-80 Project: Javassist Issue Type: Bug Affects Versions: 3.10.0.GA Environment: $ java -version java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode) Reporter: Martin Burger Assignee: Shigeru Chiba Note: Most likely this issue is related to JASSIST-79. I instrument method calls in a class called org.mozilla.javascript.TokenStream. If I run (or, load) this class, a java.lang.VerifyError will be thrown: Exception in thread "main" java.lang.VerifyError: (class: org/mozilla/javascript/TokenStream, method: getToken$JINSI_4etOXffNDXVw signature: ()I) Illegal target of jump or branch It seems Javassist introduces a defective goto statement at position 33217 in method getToken$JINSI_4etOXffNDXVw: 33217 goto 465 The corresponding Java code (excerpt): case '-': if (matchChar('=')) { this.op = SUB; c = ASSIGN; } else if (matchChar('-')) { if (0 == (flags & TSF_DIRTYLINE)) { // treat HTML end-comment after possible whitespace // after line start as comment-utill-eol if (matchChar('>')) { skipLine(); continue retry; } } c = DEC; } else { c = SUB; } flags |= TSF_DIRTYLINE; return c; I think the continue statement is related to this defect. JAD fails to decompile the instrumented class: ERROR: invalid instruction at 33217 in the method getToken$JINSI_4etOXffNDXVw. The method will be decompiled incorrectly. Javassist's framedump fails, too: Exception in thread "main" java.lang.RuntimeException: javassist.bytecode.BadBytecode: Stack is empty[pos = 465] at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:89) at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:60) at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:51) at javassist.tools.framedump.main(framedump.java:45) Caused by: javassist.bytecode.BadBytecode: Stack is empty[pos = 465] at javassist.bytecode.analysis.Analyzer.analyzeNextEntry(Analyzer.java:179) at javassist.bytecode.analysis.Analyzer.analyze(Analyzer.java:143) at javassist.bytecode.analysis.FramePrinter.print(FramePrinter.java:87) ... 3 more Caused by: java.lang.IndexOutOfBoundsException: Stack is empty at javassist.bytecode.analysis.Frame.pop(Frame.java:130) at javassist.bytecode.analysis.Executor.simplePop(Executor.java:970) at javassist.bytecode.analysis.Executor.evalStore(Executor.java:869) at javassist.bytecode.analysis.Executor.execute(Executor.java:188) at javassist.bytecode.analysis.Analyzer.analyzeNextEntry(Analyzer.java:177) ... 5 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
8
0 / 0

[JBoss JIRA] Created: (JASSIST-81) Add constants for all Java major versions in ClassFile

by Jesper Pedersen (JIRA)

Add constants for all Java major versions in ClassFile ------------------------------------------------------ Key: JASSIST-81 URL: https://jira.jboss.org/jira/browse/JASSIST-81 Project: Javassist Issue Type: Feature Request Reporter: Jesper Pedersen Assignee: Shigeru Chiba Attachments: classfile.patch javassist.bytecode.ClassFile is missing constants for some of the Java versions. Attached patch fixes this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JASSIST-84) Add support for hasAnnotation(Class) and getAnnotation(Class)

by Jesper Pedersen (JIRA)

Add support for hasAnnotation(Class) and getAnnotation(Class) ------------------------------------------------------------- Key: JASSIST-84 URL: https://jira.jboss.org/jira/browse/JASSIST-84 Project: Javassist Issue Type: Feature Request Reporter: Jesper Pedersen Assignee: Shigeru Chiba It would nice if Javassist had functionality to query boolean hasAnnotation(Class) and retrieve a single annotation Object getAnnotation(Class) for CtClass, CtBehavior and CtField. The attached implements this functionality against CVS HEAD. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2010