Causas de obtener un java.lang.VerifyError

Question

Estoy investigando lo siguiente 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)

Ocurre cuando se inicia el servidor jboss en el que está implementado el servlet.Está compilado con jdk-1.5.0_11 e intenté recompilarlo con jdk-1.5.0_15 sin éxito.Es decir, la compilación funciona bien, pero cuando se implementa, se produce java.lang.VerifyError.

Cuando cambié el nombre del método y obtuve el siguiente 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)

Puede ver que se muestra más firma del método.

La firma del método real es

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

Ya intenté mirarlo con javap y eso le da la firma al método como debería ser.

Cuando mis otros colegas revisan el código, lo compilan y lo implementan, tienen el mismo problema.Cuando el servidor de compilación recoge el código y lo implementa en entornos de desarrollo o prueba (HPUX), se produce el mismo error.Además, una máquina de prueba automatizada que ejecuta Ubuntu muestra el mismo error durante el inicio del servidor.

El resto de la aplicación funciona bien, sólo que un servlet no funciona.Cualquier idea sobre dónde buscar sería útil.

Answer 1

java.lang.VerifyError puede ser el resultado cuando ha compilado con una biblioteca diferente a la que está utilizando en tiempo de ejecución.

Por ejemplo, esto me sucedió cuando intenté ejecutar un programa que fue compilado contra Xerces 1, pero se encontró Xerces 2 en el classpath.Las clases requeridas (en org.apache.* espacio de nombres) se encontraron en tiempo de ejecución, por lo que ClassNotFoundException era no el resultado.Hubo cambios en las clases y métodos, de modo que las firmas de métodos encontradas en tiempo de ejecución no coincidían con las que había en tiempo de compilación.

Normalmente, el compilador señalará problemas en los que las firmas de los métodos no coinciden.La JVM verificará el código de bytes nuevamente cuando se cargue la clase y arroja VerifyError cuando el código de bytes intenta hacer algo que no debería permitirse, p.llamando a un método que regresa String y luego almacena ese valor de retorno en un campo que contiene un List.

Answer 2

java.lang.VerifyError son los peores.

Recibirá este error si el tamaño del código de bytes de su método excede el límite de 64 kb;pero probablemente lo habrías notado.

¿Está 100% seguro de que esta clase no está presente en el classpath de otra parte de su aplicación, tal vez en otro contenedor?

Además, de su seguimiento de pila, está la codificación de caracteres del archivo fuente (utf-8?) ¿Es eso correcto?

Answer 3

Como dijo Kevin Panko, se debe principalmente al cambio de biblioteca.Entonces, en algunos casos, una "limpieza" del proyecto (directorio) seguida de una compilación es suficiente.

Answer 4

Solucioné este error en Android haciendo que el proyecto que estaba importando fuera una biblioteca, como se describe aquí http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject

Anteriormente, solo estaba haciendo referencia al proyecto (sin convertirlo en una biblioteca) y recibía este extraño VerifyError.

Espero que ayude a alguien.

Answer 5

Una cosa que puedes probar es usar -Xverify:all que verificará el código de bytes durante la carga y, a veces, mostrará mensajes de error útiles si el código de bytes no es válido.

Answer 6

VerifyError significa que el archivo de clase contiene código de bytes que es sintácticamente correcto pero viola alguna restricción semántica, p.un objetivo de salto que cruza los límites del método.

Básicamente, un VerifyError sólo puede ocurrir cuando hay un error en el compilador o cuando el archivo de clase se corrompe de alguna otra manera (p. ej.a través de una RAM defectuosa o un disco duro defectuoso).

Intente compilar con una versión de JDK diferente y en una máquina diferente.

Answer 7

En mi caso mi proyecto de Android depende de otro proyecto de Java compilado para Java 7. java.lang.VerifyError desapareció después de que cambié el nivel de cumplimiento del compilador de ese proyecto Java a 6.0

Más tarde descubrí que se trata de un problema de Dalvik: https://groups.google.com/forum/?fromgroups#!topic/android-developers/sKsMTZ42pwE

Answer 8

Recibí este problema debido a que pack200 destrozó un archivo de clase.Un poco de búsqueda resultó en esto. error de java arriba.Básicamente, establecer --effort=4 hizo que el problema desapareciera.

Usando java 1.5.0_17 (aunque apareció en todas las variantes de java 1.5 en las que lo probé).

Answer 9

He solucionado un problema similar de java.lang.VerifyError reemplazando

        catch (MagickException e)

con

        catch (Exception e)

dónde MagickException se definió en un proyecto de biblioteca (del cual mi proyecto depende).

Después de eso tengo un java.lang.NoClassDefFoundError sobre una clase de la misma biblioteca (fijada según https://stackoverflow.com/a/9898820/755804 ).

Answer 10

Esto puede suceder en Android cuando intentas cargar una biblioteca que fue compilada con el JDK de Oracle.

Aquí está el problema para el cliente HTTP Ning Async.

Answer 11

En mi caso tuve que quitar este bloque:

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}

Estaba mostrando un error cerca Fragment.showDialog() llamada al método.

Answer 12

Ejemplo mínimo que genera el error.

Una posibilidad sencilla es utilizar Jazmín, o para editar manualmente el código de bytes con un editor de archivos binarios.

Vamos a crear void método sin return instrucción (generada por el return; declaración en Java), que el JVMS dice que es ilegal.

En Jasmin podríamos escribir:

.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

entonces hacemos javac Main.j y javap -v Main dice que hemos compilado:

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

Así que realmente no hay instrucciones de devolución.

Ahora si intentamos ejecutar java Main obtenemos:

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)

Este error nunca puede ocurrir normalmente en Java, ya que el compilador de Java agrega un return a void métodos para nosotros.Es por eso que no necesitamos agregar un return para nuestro main métodos.Puedes comprobar esto con javap.

JVMS

VerifyError ocurre cuando intenta ejecutar ciertos tipos de archivos de clase ilegales según lo especificado por JVMS 7 capítulo 4.5

El JVMS dice que cuando Java carga un archivo, debe ejecutar una serie de comprobaciones para ver que el archivo de clase esté bien antes de ejecutarlo.

Estos errores no se pueden generar en un único ciclo de compilación y ejecución de código Java, porque JVMS 7 4.10 dice:

Aunque un compilador para el lenguaje de programación Java sólo debe producir archivos de clase que satisfagan todas las restricciones estáticas y estructurales [...]

Entonces, para ver un ejemplo de falla mínima, necesitaremos generar el código fuente sin javac.

Answer 13

Esta página puede darle algunos consejos:http://www.zanthan.com/itymbi/archives/000337.html

Puede haber un error sutil en el cuerpo de ese método que javac no logra detectar.Difícil de diagnosticar a menos que publique el método completo aquí.

Podrías comenzar declarando tantas variables como sea posible como finales...eso habría detectado el error mencionado en el sitio zanthan y, de todos modos, suele ser una buena práctica.

Answer 14

Bueno, en mi caso, mi proyecto A dependía de otro, digamos X (A estaba usando algunas de las clases definidas en X).Entonces, cuando agregué X como proyecto de referencia en la ruta de compilación de A, recibí este error.Sin embargo, cuando eliminé X como proyecto al que se hace referencia e incluí el jar de X como una de las bibliotecas, el problema se resolvió.

Answer 15

Busque varias versiones del mismo archivo jar en su classpath.

Por ejemplo, tenía opennlp-tools-1.3.0.jar y opennlp-tools-1.5.3.jar en mi classpath y obtuve este error.La solución fue eliminar opennlp-tools-1.3.0.jar.

Answer 16

CGLIB < 2.2 con JRE > 6 podría provocar errores similares, consulte "¿Debo actualizar a CGLIB 3.0?" y algunos comentarios en Primavera SPR-9669.

Esto es especialmente cierto cuando todo funciona bien en JRE 6 y simplemente cambiar a JRE7 rompe las cosas.

Answer 17

Otro motivo de este error puede ser la combinación de AspectJ <= 1.6.11 con JRE > 6.

Ver Error de eclipse 353467 y Billete Kieker 307 para detalles.

Esto es especialmente cierto cuando todo funciona bien en JRE 6 y pasar a JRE7 rompe las cosas.

Answer 18

También podría suceder cuando tienes muchas importaciones de módulos con maven.Habrá dos o más clases que tendrán exactamente el mismo nombre (el mismo nombre calificado).Este error se debe a la diferencia de interpretación entre el tiempo de compilación y el tiempo de ejecución.

Answer 19

Si está migrando a java7 o utilizando java7, generalmente se puede ver este error.Me enfrenté a los errores anteriores y luché mucho para descubrir la causa raíz, sugeriría intentar agregar "-XX:-UsarSplitVerifier" Argumento JVM mientras ejecuta su aplicación.

Answer 20

Aunque la razón mencionada por Kevin es correcta, definitivamente verificaría a continuación antes de pasar a otra cosa:

1. Comprobar el cglibs en mi ruta de clase.
2. Comprobar el hibernate versiones en mi classpath.

Es muy probable que tener versiones múltiples o contradictorias de cualquiera de los anteriores pueda causar problemas inesperados como el en cuestión.

Answer 21

java.lang.VerifyError significa que su código de bytes compilado se refiere a algo que Android no puede encontrar.Este verificarError me emite sólo con kitkat4.4 y versiones menores que no están en la versión anterior De eso incluso ejecuté la misma compilación en ambos dispositivos.cuando utilicé el analizador jackson json de una versión anterior, muestra 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.+'

Luego he cambiado la Dependencia a la última versión 2.2 a 2.7 sin el biblioteca central, entonces funciona.lo que significa los Métodos y otros contenidos de centro se migra a la última versión de Enlace de datos 2.7.Esto soluciona mis problemas.

compile 'com.fasterxml.jackson.core:jackson-annotations:2.7.0-rc3'
compile 'com.fasterxml.jackson.core:jackson-databind:2.7.0-rc3'

Answer 22

elimine cualquier archivo jar inutilizable e intente ejecutarlo.y funciona para mí. Agregué un archivo jar jcommons y también otro archivo jar jcommons.1.0.14, así que eliminé jcommons y está funcionando para mí.

Answer 23

En mi caso, recibí un error de verificación con el seguimiento de la pila a continuación.

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)

Lo resolví eliminando la entrada de classpath para commons-codec-1.3.jar, había una discrepancia en la versión de este jar con la que viene con Jasper.