Causes d'obtention d'un java.lang.VerifyError

J'étudie ce qui suit 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)

Cela se produit lorsque le serveur jboss dans lequel le servlet est déployé est démarré. Il est compilé avec jdk-1.5.0_11 et j'ai essayé de le recompiler avec jdk-1.5.0_15 sans succès. C'est que la compilation fonctionne correctement mais lorsqu'elle est déployée, l'erreur java.lang.VerifyError se produit.

Lorsque j'ai changé le nom de la méthode et obtenu l'erreur suivante:

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)

Vous pouvez voir qu'une plus grande partie de la signature de la méthode est affichée.

La signature réelle de la méthode est

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

J'ai déjà essayé de le regarder avec javapet cela donne la signature de la méthode comme il se doit.

Lorsque mes autres collègues vérifient le code, le compilent et le déploient, ils ont le même problème. Lorsque le serveur de build récupère le code et le déploie sur des environnements de développement ou de test (HPUX), la même erreur se produit. Une machine de test automatisée exécutant Ubuntu montre également la même erreur lors du démarrage du serveur.

Le reste de l'application fonctionne correctement, seul ce servlet est en panne. Toute idée où chercher serait utile.

java.lang.VerifyError peut être le résultat lorsque vous avez compilé avec une bibliothèque différente de celle que vous utilisez au moment de l'exécution.

Par exemple, cela m'est arrivé en essayant d'exécuter un programme qui a été compilé avec Xerces 1, mais Xerces 2 a été trouvé sur le chemin de classe. Les classes requises (dans l' org.apache.*espace de noms) ont été trouvées au moment de l'exécution, ce ClassNotFoundExceptionn'est donc pas le cas. Il y avait eu des changements dans les classes et les méthodes, de sorte que les signatures de méthode trouvées au moment de l'exécution ne correspondaient pas à ce qui était présent lors de la compilation.

Normalement, le compilateur signalera les problèmes où les signatures de méthode ne correspondent pas. La JVM vérifiera à nouveau le bytecode lorsque la classe est chargée, et le lancera VerifyErrorlorsque le bytecode essaie de faire quelque chose qui ne devrait pas être autorisé - par exemple en appelant une méthode qui retourne Stringpuis stocke cette valeur de retour dans un champ contenant un List.

java.lang.VerifyError sont les pires.

Vous obtiendrez cette erreur si la taille du bytecode de votre méthode dépasse la limite de 64 Ko; mais vous l'auriez probablement remarqué.

Êtes-vous sûr à 100% que cette classe n'est pas présente dans le classpath ailleurs dans votre application, peut-être dans un autre fichier jar?

De plus, à partir de votre stacktrace, le codage des caractères du fichier source ( utf-8?) Est-ce correct?

Comme l'a dit Kevin Panko, c'est principalement à cause du changement de bibliothèque. Donc, dans certains cas, un "nettoyage" du projet (répertoire) suivi d'une compilation fait l'affaire.

Une chose que vous pouvez essayer est d'utiliser -Xverify:allqui vérifiera le bytecode au chargement et donne parfois des messages d'erreur utiles si le bytecode n'est pas valide.

J'ai corrigé cette erreur sur Android en créant le projet que j'importais une bibliothèque, comme décrit ici http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject

Auparavant, je faisais simplement référence au projet (sans en faire une bibliothèque) et j'obtenais cette étrange VerifyError.

J'espère que ça aide quelqu'un.

VerifyError signifie que le fichier de classe contient un bytecode qui est syntaxiquement correct mais qui viole certaines restrictions sémantiques, par exemple une cible de saut qui traverse les limites de la méthode.

Fondamentalement, une VerifyError ne peut se produire que lorsqu'il y a un bogue du compilateur, ou lorsque le fichier de classe est corrompu d'une autre manière (par exemple par une RAM défectueuse ou un HD défaillant).

Essayez de compiler avec une autre version de JDK et sur une autre machine.

Dans mon cas, mon projet Android dépend d'un autre projet Java compilé pour Java 7. java.lang.VerifyError disparu après avoir changé le niveau de conformité du compilateur de ce projet Java en 6.0

Plus tard, j'ai découvert qu'il s'agissait d'un problème Dalvik: https://groups.google.com/forum/?fromgroups#!topic/android-developers/sKsMTZ42pwE

J'obtenais ce problème en raison de la destruction par pack200 d'un fichier de classe. Un peu de recherche a résolu ce bogue Java . Fondamentalement, le réglage a --effort=4fait disparaître le problème.

En utilisant java 1.5.0_17 (bien qu'il apparaisse dans chaque variante de java 1.5 je l'ai essayé).

J'ai corrigé un problème java.lang.VerifyError similaire en remplaçant

        catch (MagickException e)

avec

        catch (Exception e)

où MagickException été défini dans un projet de bibliothèque (sur lequel mon projet a une dépendance).

Après cela, j'ai java.lang.NoClassDefFoundErrorune classe à propos de la même bibliothèque (corrigée selon https://stackoverflow.com/a/9898820/755804 ).

Cela peut se produire sur Android lorsque vous essayez de charger une bibliothèque qui a été compilée avec le JDK d'Oracle.

Voici le problème du client HTTP Ning Async.

Dans mon cas, j'ai dû supprimer ce bloc:

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}

Il montrait une erreur près de l' Fragment.showDialog()appel de méthode.

Exemple minimal qui génère l'erreur

Une possibilité simple est d'utiliser Jasmin , ou d'éditer manuellement le bytecode avec un éditeur de fichier binaire.

Permet de créer une voidméthode sans returninstruction (générée par l' return;instruction en Java), ce que le JVMS considère comme illégal.

En Jasmin, nous pourrions écrire:

.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

Nous faisons alors javac Main.jet javap -v Maindit que nous avons compilé:

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

donc vraiment il n'y a aucune instruction de retour.

Maintenant, si nous essayons de courir, java Mainnous obtenons:

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)

Cette erreur ne peut jamais se produire en Java normalement, car le compilateur Java ajoute un implicite returnaux voidméthodes pour nous. C'est pourquoi nous n'avons pas besoin d'ajouter un returnà nos mainméthodes. Vous pouvez vérifier cela avec javap.

JVMS

VerifyError se produit lorsque vous essayez d'exécuter certains types de fichiers de classe illégaux comme spécifié par JVMS 7 chapitre 4.5

Le JVMS indique que lorsque Java charge un fichier, il doit exécuter une série de vérifications pour voir que le fichier de classe est OK avant de l'exécuter.

De telles erreurs ne peuvent pas être générées sur un seul cycle de compilation et d'exécution de code Java, car JVMS 7 4.10 dit :

Même si un compilateur pour le langage de programmation Java ne doit produire que des fichiers de classe qui satisfont toutes les contraintes statiques et structurelles [...]

Donc, pour voir un exemple d'échec minimal, nous devrons générer le code source sans javac.

Cette page peut vous donner quelques conseils - http://www.zanthan.com/itymbi/archives/000337.html

Il peut y avoir un bug subtil dans le corps de cette méthode que javac ne parvient pas à repérer. Difficile à diagnostiquer sauf si vous publiez toute la méthode ici.

Vous pourriez commencer par déclarer autant de variables que possible comme finales ... cela aurait attrapé le bogue mentionné sur le site zanthan, et c'est souvent une bonne pratique de toute façon.

Eh bien dans mon cas, mon projet A était dépendant d'un autre, disons X (A utilisait certaines des classes définies dans X). Ainsi, lorsque j'ai ajouté X en tant que projet de référence dans le chemin de construction de A, j'ai eu cette erreur. Cependant, lorsque j'ai supprimé X en tant que projet référencé et inclus le jar de X comme l'une des bibliothèques, le problème a été résolu.

Recherchez plusieurs versions du même fichier jar sur votre chemin de classe.

Par exemple, j'avais opennlp-tools-1.3.0.jar et opennlp-tools-1.5.3.jar sur mon chemin de classe et j'ai obtenu cette erreur. La solution était de supprimer opennlp-tools-1.3.0.jar.

CGLIB <2.2 avec JRE> 6 pourrait déclencher des erreurs similaires, voir "Dois-je mettre à niveau vers CGLIB 3.0?" et quelques commentaires au printemps SPR-9669 .

Cela est particulièrement vrai lorsque tout fonctionne correctement sur JRE 6 et que le simple passage à JRE7 casse les choses.

Une autre raison de cette erreur peut être la combinaison de AspectJ <= 1.6.11 avec JRE> 6.

Voir Eclipse Bug 353467 et Kieker ticket 307 pour plus de détails.

Cela est particulièrement vrai lorsque tout fonctionne correctement sur JRE 6 et que le passage à JRE7 casse les choses.

Cela peut également arriver lorsque vous avez beaucoup d'importations de modules avec maven. Il y aura deux classes ou plus ayant exactement le même nom (même nom qualifié). Cette erreur est due à une différence d'interprétation entre la compilation et l'exécution.

Si vous migrez vers java7 ou utilisez java7, cette erreur est généralement visible. J'ai fait face aux erreurs ci-dessus et j'ai eu beaucoup de mal à trouver la cause principale, je suggère d'essayer d'ajouter l' argument JVM "-XX: -UseSplitVerifier" lors de l'exécution de votre application.

Après la mise Gradleà jour dans Android Studio 3.6.1, des plantages se sont produits sur l'API 19 dans la version de version.

Une erreur deGlide bibliothèque s'est produite . La solution consiste à réécrire proguard-rules.txt .

La rétrogradation Gradlefonctionne également ( classpath 'com.android.tools.build:gradle:3.5.3'), mais c'est une solution obsolète, ne l'utilisez pas.

Bien que la raison mentionnée par Kevin soit correcte, je vérifierais certainement ci-dessous avant de passer à autre chose:

1. Vérifiez le cglibsdans mon classpath.
2. Vérifiez les hibernateversions dans mon classpath.

Il est fort probable qu'une version multiple ou conflictuelle de l'un des éléments ci-dessus puisse entraîner des problèmes inattendus comme celui en question.

java.lang.VerifyError signifie que votre bytecode compilé fait référence à quelque chose qu'Android ne peut pas trouver. Cette verifyError ne me pose que kitkat4.4 et la version inférieure, pas dans la version ci-dessus, même si j'ai exécuté la même version dans les deux appareils. quand j'ai utilisé l'analyseur jackson json d'une version plus ancienne, il affiche 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.+'

Ensuite, j'ai changé la dépendance à la dernière version 2.2 à 2.7 sans la bibliothèque principale , puis cela fonctionne. ce qui signifie que les méthodes et autres contenus de core sont migrés vers la dernière version de Databind2.7 . Cela corrige mes problèmes.

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

veuillez supprimer tout fichier jar inutilisable et essayez de l'exécuter. et son travail pour moi j'ai ajouté un fichier jar jcommons et aussi un autre fichier jar jcommons.1.0.14 alors supprimez jcommons et cela fonctionne pour moi

écrire sur fichier:

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

dans les dépendances ensuite: <module name="sun.jdk"/>

Dans mon cas, j'obtenais une erreur de vérification avec la trace ci-dessous

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)

Je l'ai résolu en supprimant l'entrée de classpath pour commons-codec-1.3.jar, il y avait une incompatibilité dans la version de ce fichier avec celle fournie avec Jasper.