Causas de obtener un java.lang.VerifyError

exception deployment

Question

Estoy investigando el 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)

Se produce cuando se inicia el servidor jboss en el que se implementa el servlet. Está compilado con jdk-1.5.0_11 e intenté recompilarlo con jdk-1.5.0_15 sin éxito. Esa es la compilación funciona bien, pero cuando se implementa, se produce el 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 de la 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 traté de mirarlo con javap y eso da la firma del 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 automática que ejecuta Ubuntu muestra el mismo error durante el inicio del servidor.

El resto de la aplicación funciona bien, solo que un servlet está fuera de servicio. Cualquier idea sobre dónde buscar sería útil.

Answer 1

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

1. Comprueba los cglibs en mi classpath.
2. Verifique las versiones de hibernate en mi classpath.

Hay muchas posibilidades de que tener una versión múltiple o conflictiva de cualquiera de los anteriores pueda causar problemas inesperados como el que nos ocupa.

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

Compruebe si hay 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 6

En mi caso, mi proyecto de Android depende de otro proyecto de Java compilado para Java 7. java.lang.VerifyError desapareció después de cambiar el nivel de cumplimiento del compilador de ese proyecto de 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 7

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

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í quitando la entrada classpath para commons-codec-1.3.jar, había una falta de coincidencia en la versión de este jar con la que viene con Jasper.

Answer 8

En mi caso, tuve que eliminar este bloque:

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}

Mostraba un error cerca de la llamada al método Fragment.showDialog() .

Answer 9

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 puede detectar. Difícil de diagnosticar a menos que publiques todo el método aquí.

Podrías comenzar declarando tantas variables como sea posible como finales ... que habrían atrapado el error mencionado en el sitio de zanthan, y de todos modos es una buena práctica.

Answer 10

Estaba obteniendo este problema debido a pack200 mangling un archivo de clase. Un poco de búsqueda convirtió este error de Java . Básicamente, establecer --effort=4 provocó que el problema desapareciera.

Usando Java 1.5.0_17 (aunque surgió en cada variante de Java 1.5 lo intenté).

Answer 11

Esto puede suceder en Android cuando intenta cargar una biblioteca compilada contra el JDK de Oracle.

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

Answer 12

He solucionado un problema similar de java.lang.VerifyError al reemplazar

        catch (MagickException e)

con

        catch (Exception e)

donde se definió MagickException en un proyecto de biblioteca (en el cual mi proyecto tiene una dependencia).

Después de eso, tengo un java.lang.NoClassDefFoundError sobre una clase de la misma biblioteca (corregida de acuerdo con https://.com/a/9898820/755804 ).

Answer 13

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

Ver Eclipse Bug 353467 y Kieker ticket 307 para más detalles.

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

Answer 14

Si está migrando a java7 o usando java7, generalmente este error se puede ver. Enfrenté los errores anteriores y luché mucho para descubrir la causa raíz, sugiero que intentes agregar el argumento "-XX: -UseSplitVerifier" JVM mientras ejecutas tu aplicación.

Answer 15

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

Previamente, solo estaba haciendo referencia al proyecto (no convirtiéndolo en una biblioteca) y estaba obteniendo este extraño VerifyError.

Espero que ayude a alguien.

Answer 16

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

Answer 17

Una cosa que puede intentar es usar -Xverify:all cual verificará el bytecode en la carga y a veces da mensajes de error útiles si el bytecode no es válido.

Answer 18

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

Básicamente, un VerifyError solo puede ocurrir cuando hay un error en el compilador o cuando el archivo de clase se corrompe de alguna otra forma (por ejemplo, a través de una RAM defectuosa o un HD defectuoso).

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

Answer 19

elimine cualquier archivo jar inutilizable e intente ejecutarlo. y su trabajo para mí agregué un archivo jcommons jar y también otro archivo jcommons.1.0.14 jar así que elimine jcommons y funciona para mí

Answer 20

java.lang.VerifyError significa que su bytecode compilado se refiere a algo que Android no puede encontrar. Este verifyError me emite solo con kitkat4.4 y una versión menor, no en la versión anterior, incluso cuando 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 cambié la Dependencia a la última versión 2.2 a 2.7 sin la biblioteca central , luego funciona. lo que significa que los Métodos y otros contenidos de core se migran a la última versión de Databind2.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 21

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

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

Normalmente, el compilador señalará problemas donde las firmas de métodos no coinciden. La JVM volverá a verificar el bytecode cuando se cargue la clase, y VerifyError cuando el bytecode intente hacer algo que no debería permitirse, por ejemplo, llamar a un método que devuelve String y luego almacenar ese valor de retorno en un campo que contenga un List .

Answer 22

java.lang.VerifyError son los peores.

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

¿Estás 100% seguro de que esta clase no está presente en el classpath en otro lugar de tu aplicación, quizás en otro jar?

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

Answer 23

Ejemplo mínimo que genera el error

Una posibilidad simple es usar Jasmin , o editar manualmente el bytecode con un editor de archivos binarios.

Permite crear un método void sin una instrucción return (generada por la declaración return; 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

Luego 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 instrucción de retorno.

Ahora, si tratamos de 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 en Java normalmente, ya que el compilador de Java agrega un return implícito a los métodos void para nosotros. Es por eso que no necesitamos agregar un return a nuestros métodos main . Puedes verificar esto con javap .

JVMS

VerifyError ocurre cuando intenta ejecutar ciertos tipos de archivos de clase ilegales como se especifica en el capítulo 4.5 de JVMS 7

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

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

A pesar de que un compilador para el lenguaje de programación Java solo 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 .