134 votos

Razones de conseguir un java.lang.VerifyError

Estoy investigando el siguiente java.lang.Excepción 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 el servidor de jboss en el que el servlet es implementado se ha iniciado. Está compilado con jdk-1.5.0_11 y traté de compilar con jdk-1.5.0_15 sin éxito. Que es la compilación se ejecuta bien, pero cuando se implementa, el de java.lang.Excepción verifyerror se produce.

Cuando he cambiado el methodname y obtuve el siguiente error:

java.lang.VerifyError: (class: be/post/ehr/wfm/application/serviceorganization/r    eport/DisplayReportServlet, method: getMD signature: (IILjava/util/Collection;Lj    ava/util/Collection;Ljava/util/HashMap;Ljava/util/Collection;Ljava/util/Locale;L    org/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)

Se puede ver que más de la firma del método se muestra.

El método real de la firma es

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

Ya lo he intentado, buscando con javap y que le da a la firma del método como debe ser.

Al resto de mis compañeros compruebe el código, compilarlo e implementar, tienen el mismo problema. Cuando el servidor de compilación recoge el código y la distribuye en desarrollo o de los entornos de pruebas (HPUX), se produce el mismo error. También un sistema automatizado de pruebas de funcionamiento de la máquina ubuntu muestra el mismo error durante el inicio del servidor.

El resto de la aplicación se ejecuta bien, sólo que un servlet es fuera de orden. Cualquier idea de dónde buscar sería de gran ayuda.

138voto

Kevin Panko Puntos 4481

java.lang.VerifyError puede ser el resultado cuando se haya compilado con una biblioteca diferente de las que utiliza en tiempo de ejecución.

Por ejemplo, esto me pasó a mí cuando se intenta ejecutar un programa que fue compilado en contra de Xerces 1, pero Xerces 2 se encuentra 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. Se habían producido cambios en las clases y métodos, de modo que el método de firmas que se encuentran en tiempo de ejecución no coinciden con lo que estaba allí en tiempo de compilación.

Normalmente, el compilador de la bandera de los problemas en los que el método de las firmas no coinciden. La JVM se compruebe el código de bytes de nuevo cuando se carga la clase, y lanza VerifyError cuando el bytecode es tratando de hacer algo que no debe ser permitido-por ejemplo, llamar a un método que devuelve String y, a continuación, almacena ese valor devuelto en un campo que contiene un List.

16voto

p3t0r Puntos 1418

java.lang.VerifyError son lo peor.

Usted recibirá este error si el tamaño de código de bytes de su método supera el límite de 64 KB; pero es probable que se hubiera dado cuenta de eso.

¿Estás 100% seguro de que esta clase no está presente en la ruta de clase en otras partes de la aplicación, tal vez en otro frasco?

Asimismo, desde su StackTrace, es la codificación de caracteres del archivo de origen (UTF-8?) Correcta?

8voto

Flow Puntos 8018

Como dijo Kevin Panko, es sobre todo debido al cambio de la biblioteca. Así que en algunos casos una "limpia" del proyecto (directorio) seguido por una acumulación hace el truco.

7voto

Tiago Puntos 1234

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

Anteriormente, sólo estaba haciendo referencia al proyecto (no por lo que es una biblioteca) y que estaba recibiendo esta extraña VerifyError.

Espero que ayuda a alguien.

6voto

Alex Miller Puntos 28225

Una cosa que usted puede intentar es usar -Xverify: todos los que verificará el código de bytes de la carga y, a veces da mensajes de error útiles si el código de bytes no es válido.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X