Successfully compiled the project and build as well with Maven. This is my first maven project. But I have no idea why I'm getting the below error.
Deployeed the war on tomcat and hit my url and the below error shown in my browser.
java.lang.VerifyError: Expecting a stackmap frame at branch target 72
Exception Details:
Location:
com/ebetinc/frontend/presentation/components/Login.isToteAvailable(Ljava/lang/String;Lcom/ebetinc/frontend/dao/DatabaseDao;)Z @46: lookupswitch
Reason:
Expected stackmap frame at this location.
Bytecode:
0000000: 043d 2bb9 03a4 0100 4e2a c601 1c13 03a6
0000010: 2ab8 03aa 9900 0803 3da7 010d 2db8 03ad
0000020: 9900 692a 3a04 0236 0519 04b6 03b1 ab00
0000030: 0000 003a 0000 0002 0000 0626 0000 002c
0000040: 0000 0644 0000 001a 0019 0413 03b3 b603
0000050: b599 0017 0336 05a7 0011 1904 1303 b7b6
0000060: 03b5 9900 0604 3605 1505 ab00 0000 001c
0000070: 0000 0002 0000 0000 0000 001a 0000 0001
0000080: 0000 001a 033d a700 a02d b803 ba99 0099
0000090: 2a3a 0402 3605 1904 b603 b1ab 0000 006a
00000a0: 0000 0004 0000 af34 0000 0029 0000 af4c
00000b0: 0000 003a 0000 af4d 0000 004b 0015 51cb
00000c0: 0000 005c 1904 1303 bcb6 03b5 9900 3903
00000d0: 3605 a700 3319 0413 03be b603 b599 0028
00000e0: 0436 05a7 0022 1904 1303 c0b6 03b5 9900
00000f0: 1705 3605 a700 1119 0413 03c2 b603 b599
0000100: 0006 0636 0515 05aa 0000 001f 0000 0000
0000110: 0000 0003 0000 001d 0000 001d 0000 001d
0000120: 0000 001d 033d 1cac
Stackmap Table:
append_frame(@28,Integer,Object[#931])
append_frame(@73,Object[#200],Integer)
same_frame(@90)
same_frame(@104)
same_frame(@132)
chop_frame(@134,2)
same_frame(@137)
append_frame(@196,Object[#200],Integer)
same_frame(@213)
same_frame(@230)
same_frame(@247)
same_frame(@261)
same_frame(@292)
chop_frame(@294,2)
Can anyone throw some inputs ? Thanks for any help.
Configuration:
Java 1.7
Maven 3+
Hi this is related to some bytecode in your application. (see this note on compatibility changes for Java 7 http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#incompatibilities, look there some lines below for JSR 202)
You can either
java
with paramter -XX:-UseSplitVerifier
edit Even the answer is already a bit old. Because of a current case I add some more detailed explanation.
The StackMapTable
attribute in the class file was, even not documented at that time, introduced with Java 6.
Foo.java
public class Foo {
public static boolean bar(String s) {
if (s.length() == 0) {
return true;
}
return false;
}
}
$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
$ javac Foo.java
$ javap -c -v Foo
Compiled from "Foo.java"
public class Foo extends java.lang.Object
SourceFile: "Foo.java"
minor version: 0
major version: 50
...
public static boolean bar(java.lang.String);
Code:
Stack=1, Locals=1, Args_size=1
0: aload_0
1: invokevirtual #2; //Method java/lang/String.length:()I
4: ifne 9
7: iconst_1
8: ireturn
9: iconst_0
10: ireturn
LineNumberTable:
line 3: 0
line 4: 7
line 6: 9
StackMapTable: number_of_entries = 1
frame_type = 9 /* same */
}
The class verifier did no check if the attribute was in the class or not.
Following creates the file Foo.class
without the StackMatTable
attribute.
FooDump.java
import org.objectweb.asm.*;
import java.io.*;
public class FooDump implements Opcodes {
public static void main(String[] args) throws Exception {
FileOutputStream fos = new FileOutputStream("Foo.class");
fos.write(dump());
fos.close();
}
public static byte[] dump() throws Exception {
ClassWriter cw = new ClassWriter(0);
FieldVisitor fv;
cw.visit(V1_6, ACC_PUBLIC + ACC_SUPER, "Foo", null, "java/lang/Object",
null);
MethodVisitor mv = cw.visitMethod(ACC_PUBLIC, "<init>", "()V", null,
null);
mv.visitCode();
mv.visitVarInsn(ALOAD, 0);
mv.visitMethodInsn(INVOKESPECIAL, "java/lang/Object", "<init>", "()V",
false);
mv.visitInsn(RETURN);
mv.visitMaxs(1, 1);
mv.visitEnd();
mv = cw.visitMethod(ACC_PUBLIC + ACC_STATIC, "bar",
"(Ljava/lang/String;)Z", null, null);
mv.visitCode();
mv.visitVarInsn(ALOAD, 0);
mv.visitMethodInsn(INVOKEVIRTUAL, "java/lang/String", "length", "()I",
false);
Label l0 = new Label();
mv.visitJumpInsn(IFNE, l0);
mv.visitInsn(ICONST_1);
mv.visitInsn(IRETURN);
mv.visitLabel(l0);
// this line would generate the StackMapTable attribute
// mv.visitFrame(Opcodes.F_SAME, 0, null, 0, null);
mv.visitInsn(ICONST_0);
mv.visitInsn(IRETURN);
mv.visitMaxs(1, 1);
mv.visitEnd();
cw.visitEnd();
return cw.toByteArray();
}
}
compile and run it
$ javac -cp asm-5.2.jar:asm-util-5.2.jar:. FooDump.java
$ java -cp asm-5.2.jar:asm-util-5.2.jar:. FooDump
check that the StackMapTable
attribute is not in the file
$ javap -c -v Foo
public class Foo extends java.lang.Object
minor version: 0
major version: 50
...
public static boolean bar(java.lang.String);
Code:
Stack=1, Locals=1, Args_size=1
0: aload_0
1: invokevirtual #16; //Method java/lang/String.length:()I
4: ifne 9
7: iconst_1
8: ireturn
9: iconst_0
10: ireturn
}
FooDemo.java
public class FooDemo {
public static void main(String[] args) {
System.out.println("output: " + Foo.bar(""));
}
}
$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
$ javac FooDemo.java
$java FooDemo
output: true
With Java 7 the class verification was changed.
For class files version 50 (Java 6) the check had a failover if the StackMapTable
was missing or wrong (see: jvms-4.10.1).
Run the check with the Foo
class version of Java 6.
$ java -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
$ javap -c -v Foo
Classfile /home/suboptimal/playground/Foo.class
Last modified Jun 9, 2017; size 232 bytes
MD5 checksum 5a7ea4a5dd2f6d1bcfddb9ffd720f9c9
public class Foo
minor version: 0
major version: 50 <-- class file Java 6
...
$ javac FooDemo.java
$ java FooDemo
output: true
This failover did not occur anymore for class files version 51 (Java 7).
To create a Foo
class version of Java 7 amend the code of FooDump.java
.
// cw.visit(V1_6, ACC_PUBLIC + ACC_SUPER, "Foo", null, "java/lang/Object", null);
cw.visit(V1_7, ACC_PUBLIC + ACC_SUPER, "Foo", null, "java/lang/Object", null);
compile and run it
$ javac -cp asm-5.2.jar:asm-util-5.2.jar:. FooDump.java
$ java -cp asm-5.2.jar:asm-util-5.2.jar:. FooDump
check that it's a class version 51
$ java -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
$ javap -c -v Foo
Classfile /home/suboptimal/playground/Foo.class
Last modified Jun 9, 2017; size 232 bytes
MD5 checksum cfd57fb547ac98a1b2808549f5e9e8c1
public class Foo
minor version: 0
major version: 51 <-- class file Java 7
...
$ javac FooDemo.java
$ java FooDemo
Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9 in method Foo.bar(Ljava/lang/String;)Z at offset 4
In Java 7 the type check for the StackMapTable
attribute can be disabled to step back to the Java 6 failover mechanism using option UseSplitVerifier.
$ java -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
$ java -XX:-UseSplitVerifier FooDemo
output: true
In Java 8 the verification of the StackMapTable
attribute became mandatory and the option UseSplitVerifier
was removed.
$ java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
$ javap -c -v Foo
Classfile /home/suboptimal/playground/Foo.class
Last modified Jun 9, 2017; size 232 bytes
MD5 checksum cfd57fb547ac98a1b2808549f5e9e8c1
public class Foo
minor version: 0
major version: 51 <-- class file Java 7
...
$ javac FooDemo.java
$ java FooDemo
Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9
$ java -XX:-UseSplitVerifier FooDemo
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option UseSplitVerifier; support was removed in 8.0
Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9
note To use always the initial version of Java 6/7/8 was done by intention to show that the behaviour was there from the beginning.
You might find some suggestions to get it running with Java 8 ...
$ java -noverify FooDemo
output: true
$ java -Xverify:none FooDemo
output: true
note This disables the bytecode verifier. Keep in mind to never disable bytecode verification in a production system.
I've had the same problem running a Java 1.7 Web Application on a Java 1.7 Weblogic 12C server, while trying to deploy the error occurs:
java.lang.VerifyError: Expecting a stackmap frame at branch target 15
Exception Details: Location: aClassPathWithClassName.$javassist_write_aSpecificField(Ljava/lang/Long;)V
@6: ifnonnull Reason: Expected stackmap frame at this location.
Bytecode: 0000000: 2ab9 00cc 0100 c700 092a 2bb5 00ce b12a 0000010: 59b9 00d0 0100 2a12 d12a b400 ce2b
b900 0000020: d505 00c0 0081 b500 ceb1
From all classes within the project it happened only with the class being instrumented, aClassPathWithClassName (in the error output above).
My local solution:
Locate javassist lib being used by the application on the POM and update it. Here it was 3.10.0.GA, changed to 3.24.1-GA.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With