IP Girl
  1. IP Girl
  3. java.lang.VerifyError: Attente d’un cadre de stack de cartes à la cible de la twig JDK 1.7
Intereting Posts
Dernière version de jQuery sur le CDN de Google Générer un GUID dans Windows avec un fichier de commandes AngularJS – Modification de la valeur d’entrée d’une directive d’atsortingbut La présentation graphique de FragmentTabHost ne rend pas Saisir l’alternative Node JS au multithreading Comment append un saut de ligne dans un TextView Android? Teste si une variable est égale à l’une des deux valeurs Comment générer un métamodèle JPA 2.0? Sécurité des threads des blocs statiques en Java Erreur WCF – Impossible de trouver l’élément de noeud final par défaut qui fait référence au contrat ‘UserService.UserService’ Swift: Préfixe de classe nécessaire? Utiliser getline () en C ++ Comment augmenter la taille de tas d’une application Android? Comment convertir une chaîne Base64 en une image BitMap pour l’afficher dans un ImageView? Comment définir une action avec un formulaire simple pour?

java.lang.VerifyError: Attente d’un cadre de stack de cartes à la cible de la twig JDK 1.7

Après la mise à niveau vers JDK 1.7, je reçois une exception: 

java.lang.VerifyError: Expecting a stackmap frame at branch target 71 in method com.abc.domain.myPackage.MyClass$JaxbAccessorM_getDescription_setDescription_java_lang_Ssortingng.get(Ljava/lang/Object;)Ljava/lang/Object; at offset 20 at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2413) at java.lang.Class.getConstructor0(Class.java:2723) at java.lang.Class.newInstance0(Class.java:345) at java.lang.Class.newInstance(Class.java:327) at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:184) at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:129) at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$GetterSetterReflection.optimize(Accessor.java:384) at com.sun.xml.internal.bind.v2.runtime.property.SingleElementLeafProperty.(SingleElementLeafProperty.java:72) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:525) at com.sun.xml.internal.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:113) at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.(ClassBeanInfoImpl.java:166) at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:494) at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.(JAXBContextImpl.java:311) at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.(JAXBContextImpl.java:126) at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1148) at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:248) at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:235) at javax.xml.bind.ContextFinder.find(ContextFinder.java:445) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:637) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584) at com.abc.domain.myPackage.MyClass.marshalFacetsTest(MyClass.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:128) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) at org.testng.TestRunner.privateRun(TestRunner.java:767) at org.testng.TestRunner.run(TestRunner.java:617) at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) at org.testng.SuiteRunner.run(SuiteRunner.java:240) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1203) at org.testng.TestNG.runSuitesLocally(TestNG.java:1128) at org.testng.TestNG.run(TestNG.java:1036) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111) at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204) at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)

Java 7 a introduit une vérification plus ssortingcte et a modifié un peu le format de la classe – pour contenir une carte de stack utilisée pour vérifier que le code est correct. L’exception que vous voyez signifie qu’une méthode n’a pas de carte de stack valide.

La version Java ou l’instrumentation bytecode pourrait être à blâmer. Cela signifie généralement qu’une bibliothèque utilisée par l’application génère un bytecode invalide qui ne passe pas la vérification plus ssortingcte. Ainsi, le développeur ne peut rien faire d’autre que le signaler comme un bogue à la bibliothèque.

Pour contourner ce -noverify vous pouvez append -noverify aux arguments JVM afin de désactiver la vérification. Dans Java 7, il était également possible d’utiliser -XX:-UseSplitVerifier pour utiliser la méthode de vérification moins ssortingcte, mais cette option a été supprimée dans Java 8.

Si vous utilisez java 1.8, supprimez XX:-UseSplitVerifier et utilisez -noverify dans vos propriétés JVM.

J’ai rencontré ce problème et j’ai essayé d’utiliser le drapeau -noverify qui fonctionne vraiment. C’est à cause du nouveau vérificateur de bytecode. Donc, le drapeau devrait vraiment fonctionner. J’utilise JDK 1.7.

Note: Cela ne fonctionnerait pas si vous utilisez JDK 1.8

La seule différence entre les fichiers à l’origine du problème est le 8ème octet du fichier

CA FE BA BE 00 00 00 33 – Java 7

contre.

CA FE BA BE 00 00 00 32 – Java 6

Le paramètre -XX:-UseSplitVerifier résout le problème. Cependant, la cause de ce problème est https://bugs.eclipse.org/bugs/show_bug.cgi?id=339388

Désolé d’avoir creusé, mais j’ai rencontré le même problème et trouvé la solution plus simple.

Dans les options du compilateur Java, vous devez désélectionner “Préserver les variables locales inutilisées (jamais lues)” , il n’est donc pas nécessaire de modifier la version de la machine virtuelle Java cible.

Il semble y avoir un bug dans les anciennes versions d’Eclipe.

-noverify argument JVM à votre tâche de test. Si vous utilisez gradle, dans le build.gradle vous pouvez avoir quelque chose comme: 

 test { jvmArgs "-noverify" }

Si vous construisez le code vous-même, alors ce problème pourrait être résolu en donnant “-target 1.5” au compilateur java (ou en définissant l’option correspondante dans votre IDE ou votre configuration de compilation).

ce lien est utile. java.lang.VerifyError: Attente d’un cadre de stack

le plus simple est de changer JRE à 6.