Causes of getting a java.lang.VerifyError

Question

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.

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
I got it when using instant run in Android studio (hotswapping on compile). Turning it off did the job. — MainActivity, Commented Jan 22, 2016 at 12:03

Kevin Panko · Accepted Answer · 2011-09-28 15:44:02Z

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.

edited Sep 28, 2011 at 15:44

answered Mar 25, 2010 at 17:40

Kevin Panko

8,43619 gold badges51 silver badges62 bronze badges

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

Add a comment |

N00b Pr0grammer · Accepted Answer · 2016-09-22 12:34:15Z

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?

edited Sep 22, 2016 at 12:34

N00b Pr0grammer

4,5696 gold badges33 silver badges47 bronze badges

answered Sep 19, 2008 at 6:58

p3t0r

1,9801 gold badge16 silver badges22 bronze badges

I'm sure it is not present somewhere else. It's 43Kb, that is still a big class.
– Jeroen Wyseur
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.
– Prakash Nadar
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.
– Bhushan Karmarkar
Commented Mar 23, 2021 at 13:03

Add a comment |

Flow · Accepted Answer · 2011-03-03 17:15:01Z

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.

answered Mar 3, 2011 at 17:15

Flow

23.9k15 gold badges101 silver badges157 bronze badges

Add a comment |

Kevin Panko · Accepted Answer · 2014-10-27 13:26:58Z

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.

edited Oct 27, 2014 at 13:26

Kevin Panko

8,43619 gold badges51 silver badges62 bronze badges

answered Sep 19, 2008 at 12:14

Alex Miller

69.8k25 gold badges123 silver badges168 bronze badges

2

May I know, how do u apply -Xverify:all?
– Cheok Yan Cheng
Commented May 14, 2021 at 16:55
Big Coders do not explain things clearly, this not goes with their status
– Noor Hossain
Commented Feb 25 at 12:39

Add a comment |

Bitcoin Cash - ADA enthusiast · Accepted Answer · 2012-12-13 00:17:57Z

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.

answered Dec 13, 2012 at 0:17

Bitcoin Cash - ADA enthusiast

11.7k16 gold badges87 silver badges106 bronze badges

2

the link is no longer available, please fix it . thanks
– Mahdi Rashidi
Commented May 15, 2016 at 7:24

Add a comment |

Michael Borgwardt · Accepted Answer · 2018-02-08 07:58:38Z

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.

edited Feb 8, 2018 at 7:58

answered Jan 11, 2010 at 12:13

Michael Borgwardt

345k79 gold badges484 silver badges723 bronze badges

Add a comment |

Michal Vician · Accepted Answer · 2013-05-19 11:14:51Z

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

answered May 19, 2013 at 11:14

Michal Vician

2,5252 gold badges28 silver badges49 bronze badges

1

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

Add a comment |

Community · Accepted Answer · 2023-11-10 19:48:45Z

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).

edited Nov 10, 2023 at 19:48

CommunityBot

11 silver badge

answered May 27, 2009 at 21:03

Mike Miller

2,2571 gold badge20 silver badges26 bronze badges

Add a comment |

Community · Accepted Answer · 2017-05-23 11:54:44Z

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 ).

edited May 23, 2017 at 11:54

CommunityBot

11 silver badge

answered Apr 17, 2013 at 12:37

18446744073709551615

16.7k4 gold badges99 silver badges131 bronze badges

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

Add a comment |

Martin Konicek · Accepted Answer · 2013-05-10 09:22:57Z

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.

answered May 10, 2013 at 9:22

Martin Konicek

40.3k21 gold badges92 silver badges99 bronze badges

Have you found a solution for this yet @MartinKonicek
– Abimbola Esuruoso
Commented Feb 21, 2016 at 9:44

Add a comment |

ViliusK · Accepted Answer · 2014-04-27 16:19:19Z

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.

answered Apr 27, 2014 at 16:19

ViliusK

11.5k4 gold badges69 silver badges72 bronze badges

Add a comment |

Ciro Santilli OurBigBook.com · Accepted Answer · 2016-11-06 17:13:52Z

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.

Lars Westergren · Accepted Answer · 2008-09-19 06:57:23Z

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.

answered Sep 19, 2008 at 6:57

Lars Westergren

2,12915 silver badges26 bronze badges

1

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

Add a comment |

user2484130 · Accepted Answer · 2013-07-31 15:03:54Z

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.

answered Jul 31, 2013 at 15:03

user2484130

174 bronze badges

Add a comment |

demongolem · Accepted Answer · 2014-05-02 20:47:59Z

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.

answered May 2, 2014 at 20:47

demongolem

9,63636 gold badges94 silver badges105 bronze badges

Add a comment |

Community · Accepted Answer · 2017-05-23 12:18:11Z

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.

edited May 23, 2017 at 12:18

CommunityBot

11 silver badge

answered Sep 18, 2014 at 1:30

Alexander Wessel

3813 silver badges9 bronze badges

Add a comment |

Alexander Wessel · Accepted Answer · 2014-09-18 01:31:48Z

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.

edited Sep 18, 2014 at 1:31

answered Sep 18, 2014 at 1:26

Alexander Wessel

3813 silver badges9 bronze badges

Add a comment |

Toumi · Accepted Answer · 2015-05-04 12:09:09Z

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.

answered May 4, 2015 at 12:09

Toumi

3,1154 gold badges38 silver badges31 bronze badges

Add a comment |

Ulhas N · Accepted Answer · 2016-02-16 05:57:46Z

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.

answered Feb 16, 2016 at 5:57

Ulhas N

3265 silver badges17 bronze badges

Where to use that ?
– Noor Hossain
Commented Feb 25 at 12:38

Add a comment |

CoolMind · Accepted Answer · 2020-05-08 09:35:38Z

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.

edited May 8, 2020 at 9:35

answered Mar 4, 2020 at 16:21

CoolMind

28.1k17 gold badges199 silver badges233 bronze badges

Add a comment |

Sandeep Jindal · Accepted Answer · 2014-12-24 17:13:17Z

0

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

Check the cglibs in my classpath.
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.

answered Dec 24, 2014 at 17:13

Sandeep Jindal

15.1k19 gold badges87 silver badges123 bronze badges

Add a comment |

anand krish · Accepted Answer · 2016-02-18 12:20:56Z

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'

answered Feb 18, 2016 at 12:20

anand krish

4,3814 gold badges46 silver badges49 bronze badges

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
– anand krish
Commented Dec 4, 2017 at 9:31

Add a comment |

Jat Rahul · Accepted Answer · 2017-12-27 10:07:10Z

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

answered Dec 27, 2017 at 10:07

Jat Rahul

1

Add a comment |

suprasad · Accepted Answer · 2019-09-09 18:02:13Z

0

write on file:

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

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

edited Sep 9, 2019 at 18:02

suprasad

1,4953 gold badges18 silver badges46 bronze badges

answered Sep 9, 2019 at 16:52

Eduardo Morales

11 bronze badge

Add a comment |

tschumann · Accepted Answer · 2024-02-16 05:48:22Z

0

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

answered Feb 16 at 5:48

tschumann

3,1363 gold badges28 silver badges50 bronze badges

Add a comment |

Mahozad · Accepted Answer · 2024-02-29 07:17:04Z

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.

answered Feb 29 at 7:17

Mahozad

22.4k17 gold badges146 silver badges168 bronze badges

Add a comment |

muneebShabbir · Accepted Answer · 2018-01-04 05:43:46Z

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.

Collectives™ on Stack Overflow

Causes of getting a java.lang.VerifyError

27 Answers 27

Your Answer

Not the answer you're looking for? Browse other questions tagged
java
exception
deployment
runtime-error
verifyerror
or ask your own question.

Linked

Hot Network Questions

Collectives™ on Stack Overflow

27 Answers 27

Your Answer

Sign up or log in

Post as a guest

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

Linked

Related

Not the answer you're looking for? Browse other questions tagged
java
exception
deployment
runtime-error
verifyerror
or ask your own question.