Les Causes de l'obtention d'un java.lang.Exception verifyerror

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 chemin de classe ailleurs dans votre application, peut-être dans un autre pot?

Aussi, à partir de votre stacktrace, est le codage de caractères du fichier source (utf-8?) Est-ce exact?

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

J'ai corrigé cette erreur sur Android en faisant 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 (ne pas en faire une bibliothèque) et j'obtenais cette étrange VerifyError.

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

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

VerifyError signifie que le fichier de classe contient un bytecode syntaxiquement correct mais viole une restriction sémantique, 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 via une RAM défectueuse ou une HD défaillante).

Essayez de compiler avec une version JDK différente et sur une machine différente.

Dans mon cas, mon projet Android dépend d'un autre projet Java compilé pour Java 7. java.lang.VerifyError a 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-développeurs / sKsMTZ42pwE

J'ai eu ce problème en raison de pack200 mangeant un fichier de classe. Un peu de recherche a transformé ce bogue java. Fondamentalement, le réglage --effort=4 a fait disparaître le problème.

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

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

        catch (MagickException e)

Avec

        catch (Exception e)

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

Après cela, j'ai un java.lang.NoClassDefFoundError à propos d'une classe de la même bibliothèque (fixé 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 pour Ning Async HTTP client.

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

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}

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

Exemple Minimal qui génère l'erreur

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

Permet de créer une méthode void sans une instruction return (générée par l'instruction return; en Java), ce que les JVM disent illégal.

Dans 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.j et javap -v Main dit 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 pas de retour instruction.

Maintenant, si nous essayons d'exécuter java Main on obtient:

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 return implicite aux méthodes void pour nous. C'est pourquoi nous n'avons pas besoin d'ajouter un return notre main méthodes. Vous pouvez vérifier cela avec javap.

JVM

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 JVM dit 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 la source code sans javac.

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

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

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

Eh bien dans mon cas, mon projet A avait une dépendance sur un autre, disons X(A utilisait certaines des classes définies dans X). Donc, quand j'ai ajouté X comme 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-outils-1.5.3.jar sur mon chemin de classe et a obtenu cette erreur. La solution consistait à supprimer opennlp-tools-1.3.0.pot.

CGLIB 6 pourrait déclencher des erreurs similaires, voir "Dois-je mettre à niveau vers CGLIB 3.0?"et quelques commentaires à Spring SPR-9669.

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

Une autre raison de cette erreur peut être la combinaison d'AspectJ 6.

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

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

Cela peut également se produire 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 résulte d'une différence d'interprétation entre le temps de compilation et l'exécution.

Si vous migrez vers java7 ou utilisez java7, cette erreur peut généralement être vue. J'ai fait face aux erreurs ci-dessus et j'ai beaucoup lutté pour trouver la cause première, je suggère d'essayer d'ajouter "-XX: - UseSplitVerifier" argument JVM lors de l'exécution de votre application.

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

1. Vérifiez le cglibs dans mon chemin de classe.
2. Vérifiez les versions hibernate dans mon chemin de classe.

Il y a de bonnes chances qu'une version multiple ou contradictoire de l'un des éléments ci-dessus puisse causer 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 délivre qu'avec kitkat4.4 et une version moindre pas dans la version ci-dessus de cela même j'ai exécuté la même construction dans les deux appareils. lorsque j'ai utilisé l'analyseur jackson json d'une ancienne version, il montre java.lang.exception 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.+'

, Puis j'ai changé la Dépendance à l' dernière version 2.2 à 2.7 sans les bibliothèque de base, alors cela fonctionne. ce qui signifie les Méthodes et contenus de base est migré vers la dernière version de Databind2.7. Ce correctif de mes Questions.

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 essayer de l'exécuter. et son travail pour moi, j'ai ajouté un fichier jar jcommons et aussi un autre jcommons.1.0.14 fichier jar donc supprimer jcommons et son travail pour moi

Dans mon cas, je recevais une erreur de vérification avec la trace de pile 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 classpath pour commons-codec-1.3.jar, il y avait un décalage dans la version de ce jar avec celui livré avec Jasper.