207

I'm investigating the following java.lang.VerifyError:

java.lang.VerifyError: (class: be/post/ehr/wfm/application/serviceorganization/report/DisplayReportServlet, method: getMonthData signature: (IILjava/util/Collection;Ljava/util/Collection;Ljava/util/HashMap;Ljava/util/Collection;Ljava/util/Locale;Lorg/apache/struts/util/MessageRe˜̴Mt̴MÚw€mçw€mp:”MŒŒ
                at java.lang.Class.getDeclaredConstructors0(Native Method)
                at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
                at java.lang.Class.getConstructor0(Class.java:2671)

It occurs when the jboss server in which the servlet is deployed is started. It is compiled with jdk-1.5.0_11 and I tried to recompile it with jdk-1.5.0_15 without succes. That is the compilation runs fine but when deployed, the java.lang.VerifyError occurs.

When I changed the method name and got the following error:

java.lang.VerifyError: (class: be/post/ehr/wfm/application/serviceorganization/report/DisplayReportServlet, method: getMD signature: (IILjava/util/Collection;Lj    ava/util/Collection;Ljava/util/HashMap;Ljava/util/Collection;Ljava/util/Locale;Lorg/apache/struts/util/MessageResources ØÅN|ØÅNÚw€mçw€mX#ÖM|XÔM
            at java.lang.Class.getDeclaredConstructors0(Native Method)
            at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357
            at java.lang.Class.getConstructor0(Class.java:2671)
            at java.lang.Class.newInstance0(Class.java:321)
            at java.lang.Class.newInstance(Class.java:303)

You can see that more of the method signature is shown.

The actual method signature is:

  private PgasePdfTable getMonthData(int month, int year, Collection dayTypes,
                          Collection calendarDays,
                          HashMap bcSpecialDays,
                          Collection activityPeriods,
                          Locale locale, MessageResources resources) throws   Exception {

I already tried looking at it with javap and that gives the method signature as it should be.

When my other colleagues check out the code, compile it and deploy it, they have the same problem. When the build server picks up the code and deploys it on development or testing environments (HPUX), the same error occurs. Also an automated testing machine running Ubuntu shows the same error during server startup.

The rest of the application runs okay, only that one servlet is out of order. Any ideas where to look would be helpful.

2
  • 1
    I got it from using the wrong version of ComparisonFailure. Took FOREVER to find...that was painful
    – Tim Boland
    Commented Aug 21, 2015 at 0:40
  • 1
    I got it when using instant run in Android studio (hotswapping on compile). Turning it off did the job. Commented Jan 22, 2016 at 12:03

27 Answers 27

202

java.lang.VerifyError can be the result when you have compiled against a different library than you are using at runtime.

For example, this happened to me when trying to run a program that was compiled against Xerces 1, but Xerces 2 was found on the classpath. The required classes (in org.apache.* namespace) were found at runtime, so ClassNotFoundException was not the result. There had been changes to the classes and methods, so that the method signatures found at runtime did not match what was there at compile-time.

Normally, the compiler will flag problems where method signatures do not match. The JVM will verify the bytecode again when the class is loaded, and throws VerifyError when the bytecode is trying to do something that should not be allowed -- e.g. calling a method that returns String and then stores that return value in a field that holds a List.

2
  • 3
    One thing to add, sometimes it's the IDE's fault, or the device that the bytecode isn't right. Try restarting the IDE to get it to recognize the sync issue. Failing that delete and re-install the app. Rebooting the device may also help.
    – ima747
    Commented Dec 19, 2014 at 17:03
  • 5
    To find out which class is the culprit add the VM argument -verbose:class and then look for the class just before it loads java.lang.VerifyError. This will have the path to the JAR. Use javap and compare that to the class you are compiling against. I found this useful as the class that was reported in the error was not the cause it was actually one of the arguments.
    – steinybot
    Commented Aug 16, 2016 at 2:47
23

java.lang.VerifyError are the worst.

You would get this error if the bytecode size of your method exceeds the 64kb limit; but you would probably have noticed that.

Are you 100% sure this class isn't present in the classpath elsewhere in your application, maybe in another jar?

Also, from your stacktrace, is the character encoding of the source file (utf-8?) Is that correct?

4
  • I'm sure it is not present somewhere else. It's 43Kb, that is still a big class. Commented Sep 23, 2008 at 11:40
  • Thanks for that post, in my case, it was an different encoding: JasperReports XMl files save an encoding and a java version, you have to set this accordingly to your project settings (via iReport). That was the problem here, thanks for your idea with the encoding! :)
    – Tobias
    Commented Feb 16, 2011 at 11:44
  • This was my problem for android tests, multidexing it fixed it. Commented Dec 13, 2018 at 6:23
  • Thanks @p3t0r ! For me there were two ojdbc jars being loaded on classpath. removing one resolved the issue. Commented Mar 23, 2021 at 13:03
11

As Kevin Panko said, it's mostly because of library change. So in some cases a "clean" of the project (directory) followed by a build does the trick.

9

One thing you might try is using -Xverify:all which will verify bytecode on load and sometimes gives helpful error messages if the bytecode is invalid.

2
  • 2
    May I know, how do u apply -Xverify:all? Commented May 14, 2021 at 16:55
  • Big Coders do not explain things clearly, this not goes with their status Commented Feb 25 at 12:39
8

I fixed this error on Android by making the project I was importing a library, as described here http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject

Previously, I was just referencing the project (not making it a library) and I was getting this strange VerifyError.

Hope it helps someone.

1
  • 2
    the link is no longer available, please fix it . thanks Commented May 15, 2016 at 7:24
8

VerifyError means that the class file contains bytecode that is syntactically correct but violates some semantic restriction e.g. a jump target that crosses method boundaries.

Basically, a VerifyError can only occur when there is a compiler bug, or when the class file gets corrupted in some other way (e.g. through faulty RAM or a failing HD).

Try compiling with a different JDK version and on a different machine.

5

In my case my Android project depends on another Java project compiled for Java 7. java.lang.VerifyError disappeared after I changed Compiler Compliance Level of that Java project to 6.0

Later I found out that this is a Dalvik issue: https://groups.google.com/forum/?fromgroups#!topic/android-developers/sKsMTZ42pwE

1
  • 1
    Dalvik is just a branched version of Java6 so no Java7 features are available! Commented May 23, 2013 at 11:41
4

I was getting this problem due to pack200 mangling a class file. A bit of searching turned this java bug up. Basically, setting --effort=4 caused the problem to go away.

Using java 1.5.0_17 (though it cropped up in every single variant of java 1.5 I tried it in).

3

I have fixed a similar java.lang.VerifyError issue by replacing

        catch (MagickException e)

with

        catch (Exception e)

where MagickException was defined in a library project (on which my project has a dependency).

After that I have got a java.lang.NoClassDefFoundError about a class from the same library (fixed according to https://stackoverflow.com/a/9898820/755804 ).

2
  • 1
    This worked for me... I'd really like to figure out what the error was besides "replace me with a blanket exception and I'll work" though.
    – Alex Hart
    Commented Dec 3, 2013 at 20:39
  • @AlexHart it's for Android, but likely the same logic would apply for enterprise Java: stackoverflow.com/a/36814155/253468
    – TWiStErRob
    Commented Apr 24, 2016 at 15:35
3

This can happen on Android when you're trying to load a library that was compiled against Oracle's JDK.

Here is the problem for Ning Async HTTP client.

1
  • Have you found a solution for this yet @MartinKonicek Commented Feb 21, 2016 at 9:44
2

In my case I had to remove this block:

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}

It was showing error near Fragment.showDialog() method call.

2

Minimal example that generates the error

One simple possibility is to use Jasmin, or to manually edit the bytecode with a binary file editor.

Lets create void method without a return instruction (generated by the return; statement in Java), which the JVMS says is illegal.

In Jasmin we could write:

.class public Main
.super java/lang/Object

.method public static main([Ljava/lang/String;)V
   aload_0 ; Just so that we won't get another verify error for empty code.
.end method

We then do javac Main.j and javap -v Main says that we have compiled:

public static void main(java.lang.String[]);
  descriptor: ([Ljava/lang/String;)V
  flags: ACC_PUBLIC, ACC_STATIC
  Code:
    stack=1, locals=1, args_size=1
       0: aload_0

so really there is no return instruction.

Now if we try to run java Main we get:

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.VerifyError: (class: NoReturn, method: main signature: ([Ljava/lang/String;)V) Falling off the end of the code
        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
        at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
        at java.lang.Class.getMethod0(Class.java:3018)
        at java.lang.Class.getMethod(Class.java:1784)
        at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)

This error can never happen in Java normally, since the Java compiler adds an implicit return to void methods for us. This is why we don't need to add a return to our main methods. You can check this with javap.

JVMS

VerifyError happens when you try to run certain types of illegal class file as specified by JVMS 7 chapter 4.5

The JVMS says that when Java loads a file, it must run a series of checks to see that the class file is OK before running it.

Such errors cannot be generated on a single compile and run cycle of Java code, because JVMS 7 4.10 says:

Even though a compiler for the Java programming language must only produce class files that satisfy all the static and structural constraints [... ]

So to see a minimal failure example, we will need to generate the source code without javac.

1

This page may give you some hints - http://www.zanthan.com/itymbi/archives/000337.html

There may be a subtle bug in the body of that method that javac fails to spot. Difficult to diagnose unless you post the whole method here.

You could start by declaring as many variables as possible as final... that would have caught the bug mentioned on the zanthan site, and is often a good practice anyways.

1
  • 1
    That guy hit a compiler bug back in 2002, but that bug has been fixed since then. Commented Mar 25, 2010 at 19:22
1

Well in my case, my project A had a dependency on another, say X(A was using some of the classes defined in X). So when I added X as a reference project in the build path of A , I got this error. However when I removed X as the referenced project and included X's jar as one of the libraries, the problem was solved.

1

Check for multiple versions of the same jar file on your classpath.

For example, I had opennlp-tools-1.3.0.jar and opennlp-tools-1.5.3.jar on my classpath and got this error. The solution was to delete opennlp-tools-1.3.0.jar.

1

CGLIB < 2.2 with JRE > 6 could trigger similar errors, see "Should I upgrade to CGLIB 3.0?" and some commentary at Spring SPR-9669.

This is especially true when everything works fine on JRE 6 and simply switching to JRE7 breaks things.

1

Another reason for this error can be the combination of AspectJ <= 1.6.11 with JRE > 6.

See Eclipse Bug 353467 and Kieker ticket 307 for details.

This is especially true when everything works fine on JRE 6 and moving to JRE7 breaks things.

1

It could also happen when you have a lot of module imports with maven. There will be two or more classes having exactly the same name ( same qualified name). This error is resulting from difference of interpretation between compile time and runtime.

1

If you are migrating to java7 or using java7 then generally this error can be seen. I faced above errors and struggled a lot to find out the root cause, I would suggest to try adding "-XX:-UseSplitVerifier" JVM argument while running your application.

1
  • Where to use that ? Commented Feb 25 at 12:38
1

After updating Gradle in Android Studio 3.6.1 crashes happened on API 19 in release build.

There was a Glide library error. Solution is to rewrite proguard-rules.txt.

Also downgrading Gradle works (classpath 'com.android.tools.build:gradle:3.5.3'), but it is an outdated solution, don't use it.

0

Though the reason mentioned by Kevin is correct, but I would definitely check below before moving to something else:

  1. Check the cglibs in my classpath.
  2. Check the hibernate versions in my classpath.

Chances are good that having multiple or conflicting version of any of the above could cause unexpected issues like the one in question.

0

java.lang.VerifyError means your compiled bytecode is referring to something that Android cannot find. This verifyError Issues me only with kitkat4.4 and lesser version not in above version of that even I ran the same build in both Devices. when I used jackson json parser of older version it shows java.lang.verifyerror

compile 'com.fasterxml.jackson.core:jackson-databind:2.2.+'
compile 'com.fasterxml.jackson.core:jackson-core:2.2.+'
compile 'com.fasterxml.jackson.core:jackson-annotations:2.2.+'

Then I have changed the Dependancy to the latest version 2.2 to 2.7 without the core library, then it works. which means the Methods and other contents of core is migrated to the latest version of Databind2.7. This fix my Issues.

compile 'com.fasterxml.jackson.core:jackson-annotations:2.7.0-rc3'
compile 'com.fasterxml.jackson.core:jackson-databind:2.7.0-rc3'
2
  • How do you know which JAR to look for ?
    – Siddharth
    Commented Dec 3, 2017 at 4:33
  • 1
    jackson-core:2.2.+ is became legacy. so we need to use databind:2.7.0-rc3, annotations:2.7.0-rc3 or latest version than this. This 2 is enough, avoid jackson-core:2.2.+ . I got some verifyerror by that time. while using 2.7+ version it doesn't show that error Commented Dec 4, 2017 at 9:31
0

please remove any unusable jar file and try to run. and its work for me i added a jcommons jar file and also another jcommons.1.0.14 jar file so remove jcommons and its working for me

0

write on file:

{Wildfly-home}\modules\system\layers\base\org\picketbox\main 

into dependencies next: <module name="sun.jdk"/>

0

I got this error when using Groovy 2.4 on Java 17 - upgrading to Groovy 2.5 fixed the issue.

0

In my Compose Multiplatform project, the reason was Proguard 7.4.2 and its optimization.

So, I disabled Proguard optimization by adding this line to my rules.pro file:

-dontoptimize

See the related GitHub issue in Compose Multiplatform repository.

-2

In my case, I was getting verify error with below stack trace

jasperreports-server-cp-6.4.0-bin\buildomatic\build.xml:61: The following error occurred while executing this line:
TIB_js-jrs-cp_6.4.0_bin\jasperreports-server-cp-6.4.0-bin\buildomatic\bin\setup.xml:320: java.lang.VerifyError: (class: org/apache/commons/codec/binary/Base64OutputStream, method: <init> signature: (Ljava/io/OutputStream;ZI[B)V) Incompatible argument to function
    at com.jaspersoft.jasperserver.crypto.KeystoreManager.createKeystore(KeystoreManager.java:257)
    at com.jaspersoft.jasperserver.crypto.KeystoreManager.init(KeystoreManager.java:224)
    at com.jaspersoft.buildomatic.crypto.KeystoreTask.execute(KeystoreTask.java:64)
    at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
    at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
    at org.apache.tools.ant.Task.perform(Task.java:348)
    at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
    at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
    at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
    at org.apache.tools.ant.Task.perform(Task.java:348)
    at org.apache.tools.ant.Target.execute(Target.java:435)
    at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:169)
    at org.apache.tools.ant.taskdefs.ImportTask.importResource(ImportTask.java:222)
    at org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:163)
    at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
    at org.apache.tools.ant.Task.perform(Task.java:348)
    at org.apache.tools.ant.Target.execute(Target.java:435)
    at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:180)
    at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:93)
    at org.apache.tools.ant.Main.runBuild(Main.java:826)
    at org.apache.tools.ant.Main.startAnt(Main.java:235)
    at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
    at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)

I got it resolved by removing classpath entry for commons-codec-1.3.jar, there was a mismatch in version of this jar with the one comes with Jasper.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.