Getting "Caused By: Java.Lang.Verifyerror:"

Causes of getting a java.lang.VerifyError

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.

WorkManager: java.lang.VerifyError: Verifier rejected class androidx.work.impl.OperationImpl

The solution was a tad weird, I admit.

My first step was to update the dependency versions for WorkManager as well as Coroutines to the latest versions (as stated in the question details). After that, I updated the provider<> tag in my AndroidManifest.xml file from this:

<provider
android:name="androidx.work.impl.WorkManagerInitializer"
android:authorities="${applicationId}.workmanager-init"
tools:node="remove" />

to this:

<provider
android:name="androidx.startup.InitializationProvider"
android:authorities="${applicationId}.androidx-startup"
android:exported="false"
tools:node="merge" />

After that, everything just worked fine. /p>

debugging a java.lang.VerifyError

What is the full stack trace? It should show that which class is calling that method. Probably the reason is that the code is being executed against a different version of the library that it was compiled against, and there is some incompatible change between those library versions (from the error message it appears to be a different method return type).

If that error is not about any library, but about your own code, then do a clean build. The compiler should produce a compile error about all things which may cause a verify error at runtime. Or if the source code is correct, it should rebuild all the class files correctly.

java.lang.VerifyError on method that worked a minute ago

A VerifyError means the bytecode is invalid, which points to a compiler problem. I would try rebuilding everything in the hopes that it goes away, but otherwise you should file a bug. The bytecode is required to call the superclass constructor manually via invokenonvirtual superclass/<init>()V, but you shouldn't need to add super(); in the source, the compiler should handle that

java.lang.VerifyError:Illegal type in constant pool

This is now solved, it was probably caused by bytecode size of one of my methods exceeded the 64kb limit. Causes of getting a java.lang.VerifyError

Java.lang.VerifyError

AUTHav.class is corrupt (sometimes?). Obviously some method is declared to throw something that is not a subclass of Throwable. Usually this shouldn't happen because a Java compiler would detect that problem and report an error. But maybe the class file is modified/instrumented or even generated at runtime and this introduces the sporadic error. Or you have a naming conflict and the classloaded sporadically sees a diffenent, non-Throwable class instead of the intended one.

If AUTHav.class is contained in some archive, you could have a look at the byte code (with javap or a decompiler) and check if you find a method with a suspicious throws argument.


So the byte code is obfuscated ... then it could be - and this is just a guess - that you have more than one version of the library inside your J2EE container. As the classes are obfuscated, there is a chance that the class names AUTHa7 and/or AUTHa1 are used for different (orginal) classes in different versions of the library. And then, if the classloader picks up both or maybe the wrong one at the wrong time, it could happen, that AUTHa7 and/or AUTHa1 are not Exceptions at runtime...



Related Topics



Leave a reply



Submit