java.lang.VerifyError: Expecting a stackmap frame at branch target JDK 1.7

Question

After upgrading to JDK 1.7 I am getting below exception:

java.lang.VerifyError: Expecting a stackmap frame at branch target 71 in method com.abc.domain.myPackage.MyClass$JaxbAccessorM_getDescription_setDescription_java_lang_String.get(Ljava/lang/Object;)Ljava/lang/Object; at offset 20
    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:2413)
    at java.lang.Class.getConstructor0(Class.java:2723)
    at java.lang.Class.newInstance0(Class.java:345)
    at java.lang.Class.newInstance(Class.java:327)
    at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:184)
    at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:129)
    at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$GetterSetterReflection.optimize(Accessor.java:384)
    at com.sun.xml.internal.bind.v2.runtime.property.SingleElementLeafProperty.<init>(SingleElementLeafProperty.java:72)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
    at com.sun.xml.internal.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:113)
    at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:166)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:494)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:311)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:126)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1148)
    at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:130)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:248)
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:235)
    at javax.xml.bind.ContextFinder.find(ContextFinder.java:445)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:637)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584)
    at com.abc.domain.myPackage.MyClass.marshalFacetsTest(MyClass.java:73)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
    at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
    at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
    at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
    at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:128)
    at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
    at org.testng.TestRunner.privateRun(TestRunner.java:767)
    at org.testng.TestRunner.run(TestRunner.java:617)
    at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
    at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
    at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
    at org.testng.SuiteRunner.run(SuiteRunner.java:240)
    at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
    at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
    at org.testng.TestNG.runSuitesSequentially(TestNG.java:1203)
    at org.testng.TestNG.runSuitesLocally(TestNG.java:1128)
    at org.testng.TestNG.run(TestNG.java:1036)
    at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
    at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
    at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)

score 175 · Answer 1 · edited Jan 18 '17 at 22:15

175

Java 7 introduced stricter verification and changed the class format a bit—to contain a stack map used to verify that code is correct. The exception you see means that some method doesn't have a valid stack map.

Java version or bytecode instrumentation could both be to blame. Usually this means that a library used by the application generates invalid bytecode that doesn't pass the stricter verification. So nothing else than reporting it as a bug to the library can be done by the developer.

As a workaround you can add -noverify to the JVM arguments in order to disable verification. In Java 7 it was also possible to use -XX:-UseSplitVerifier to use the less strict verification method, but that option was removed in Java 8.

edited Jan 18 '17 at 22:15

kuporific

10,053
3
42
46

answered Feb 27 '13 at 21:40

Mirko Adari

5,083
1
15
23

1

But what does -XX:-UseSplitVerifier mean?? I looked at oracle's explaination,It says "Use the new type checker with StackMapTable attributes". I didn't get it. – Sanguine Feb 28 '13 at 18:16
2

So if I see this errors: Is this a bug within the JVM or my code? – bentolor May 29 '13 at 11:30
4

this answer is not valid in the long terms, or perhaps any longer already, as Oracle is deprecating this option. I'm afflicted by this bug (with other code) and am looking for a way to fore rebuild of stackmaps – ZiglioUK Oct 14 '13 at 03:50
Does anyone has an idea about what if the same situation but runs on a linux machine? I got the error that "-XX:-UseSplitVerifier: command not found". – huao Apr 13 '15 at 23:31
After using UseSplitVerifier and noverify options, the byte code validation error goes away. But then I get a new error: NoClassDefFoundError. I am using jdk1.7.0_76 on OS X 10.10.3. – devdanke Jun 19 '15 at 21:00
2

for unit test you have to pass the arguments in the surefire plugin. This fixed the issue for both java 7 and 8 compilers: org.apache.maven.plugins maven-surefire-plugin 2.18.1 -noverify -XX:-UseSplitVerifier – Antoine Wils Aug 17 '15 at 13:33
1

I've had exactly the same issue on Java 1.8, and the option -noverify did the work. Is there anything better to fix it? – FiReTiTi Apr 22 '16 at 08:33
2

i was facing the same issue but after adding -noverify it really worked for me.Thanks. – Praveen Kumar Mekala Aug 17 '16 at 06:50
-noverify also worked for me. I'm using gradle for Android and so I had to put the -noverify flag where specified in https://stackoverflow.com/a/37593189/2848676 – Michael Osofsky Jul 17 '17 at 16:38

score 16 · Answer 2 · edited Jan 28 '16 at 11:59

16

If you are using java 1.8, remove XX:-UseSplitVerifier and use -noverify in your JVM properties.

edited Jan 28 '16 at 11:59

dur

15,689
25
79
125

answered Jan 28 '16 at 11:16

Anand Kumar K K

169
1
2

score 8 · Answer 3 · edited Jun 15 '16 at 05:37

8

I ran into this problem and try using the flag -noverify which really works. It is because of the new bytecode verifier. So the flag should really work. I am using JDK 1.7.

Note: This would not work if you are using JDK 1.8

edited Jun 15 '16 at 05:37

Jens

67,715
15
98
113

answered Feb 03 '15 at 02:21

Charan Raj

471
5
8

3

For me using the flag fixed executing our Android Unit Tests using JRE 8 as a runtime. – ubuntudroid Sep 23 '15 at 11:41
2

-noverify also worked for me on Java 8. I'm using gradle for Android and so I had to put the -noverify flag where specified in stackoverflow.com/a/37593189/2848676 – Michael Osofsky Jul 17 '17 at 16:39
where did you set -noverify? I set it as MAVEN_OPTS but its not working for me – dev Jul 26 '17 at 07:02
1

@Sara Antunez, In your application modules' build.gradle file in android closure, add this. android { .... testOptions { unitTests.all { jvmArgs '-noverify' } } } – ALearner Sep 14 '17 at 19:47

score 4 · Answer 4 · edited Jul 06 '18 at 01:13

4

Pass -noverify JVM argument to your test task. If you are using gradle, in the build.gradle you can have something like:

test {
  jvmArgs "-noverify"
}

edited Jul 06 '18 at 01:13

Stephen Rauch

47,830
31
106
135

answered Jul 06 '18 at 00:51

Leo

121
1
7

A Kunin · Answer 5 · 2016-11-02T07:05:50.250

2

The only difference between files that causing the issue is the 8th byte of file

CA FE BA BE 00 00 00 33 - Java 7

vs.

CA FE BA BE 00 00 00 32 - Java 6

Setting -XX:-UseSplitVerifier resolves the issue. However, the cause of this issue is https://bugs.eclipse.org/bugs/show_bug.cgi?id=339388

edited Nov 02 '16 at 07:05

answered Nov 02 '16 at 02:41

A Kunin

42,385
1
17
13

score 0 · Answer 6 · answered May 04 '20 at 12:16

0

This ERROR can happen when you use Mockito to mock final classes.

Consider using Mockito inline or Powermock instead.

answered May 04 '20 at 12:16

nhoxbypass

9,695
11
48
71

score 0 · Answer 7 · answered Oct 21 '22 at 13:10

0

I had a similar issue that was caused by the -preverify flag. Removing that flag fixed the issue for me. JVM 1.7+ is incompatible with that option. https://www.guardsquare.com/manual/configuration/usage#dontpreverify

answered Oct 21 '22 at 13:10

Sean

2,632
2
27
35

score -2 · Answer 8 · answered Oct 16 '13 at 14:38

-2

Sorry for digging, but I met the same problem and found the simplier solution.

In Java compiler options you need to uncheck "Preserve unused (never read) local variables" so there is no need to change back target JVM version.

It seems to be a bug in an older Eclipe versions.

answered Oct 16 '13 at 14:38

scoro

13
3

it doesn't work for me. Here's a gist of my error: https://gist.github.com/ZiglioNZ/bd1d7d424727b3f26c64 – ZiglioUK Oct 20 '13 at 11:28
3

The OP doesn't mention Eclipse. He may not even be using it. – Don Branson Nov 01 '13 at 19:52

score -4 · Answer 9 · answered Aug 09 '14 at 16:41

-4

If you are building the code yourself, then this issue could be overcome by giving "-target 1.5" to the java compiler (or by setting the corresponding option in your IDE or your build config).

answered Aug 09 '14 at 16:41

jrajp2184

310
1
9

score -11 · Answer 10 · edited May 23 '17 at 11:55

-11

this link is helpful. java.lang.VerifyError: Expecting a stackmap frame

the simplest way is changing JRE to 6.

edited May 23 '17 at 11:55

Community

1
1

answered May 23 '13 at 05:45

yuxiaomin

71
1
3

7

downgrading when a simple JVM arg can fix? I doubt your definition of simple. – Visionary Software Solutions Jun 14 '13 at 12:50
1

Whilst this may theoretically answer the question, [it would be preferable](http://meta.stackexchange.com/q/8259) to include the essential parts of the answer here, and provide the link for reference. – Joachim Sauer Sep 09 '13 at 08:47
This is a work around. As Joachim said, it may work - but it doesn't define the problem or help for teams or code bases that must use Java 7 – Crowie Nov 15 '13 at 14:09
There are multiple answers in the linked question. Downgrading is only one listed option. – Ogre Psalm33 Oct 13 '14 at 19:50

java.lang.VerifyError: Expecting a stackmap frame at branch target JDK 1.7

10 Answers10

Linked

Related