it-swarm.com.de

Ursachen für das Erhalten eines Java.lang.VerifyError

Ich untersuche den folgenden 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)

Es tritt auf, wenn der jboss-Server, auf dem das Servlet implementiert ist, gestartet wird .. _. Es wird mit jdk-1.5.0_11 kompiliert und ich habe versucht, es ohne Erfolg mit jdk-1.5.0_15 neu zu kompilieren. Die Kompilierung läuft zwar einwandfrei, aber bei der Bereitstellung tritt Java.lang.VerifyError auf.

Wenn ich den Methodennamen geändert habe und die folgende Fehlermeldung angezeigt wurde:

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)

Sie können sehen, dass mehr von der Methodensignatur angezeigt wird.

Die eigentliche Methodensignatur lautet

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

Ich habe schon versucht, es mit javap anzusehen, und das gibt die Methodensignatur so, wie sie sein sollte.

Wenn meine anderen Kollegen den Code auschecken, kompilieren und bereitstellen, haben sie das gleiche Problem. Wenn der Buildserver den Code aufnimmt und in Entwicklungs- oder Testumgebungen (HPUX) bereitstellt, tritt der gleiche Fehler auf. Auch eine automatisierte Testmaschine, die Ubuntu ausführt, zeigt den gleichen Fehler während des Serverstarts.

Der Rest der Anwendung läuft in Ordnung, nur dass ein Servlet nicht in Ordnung ist. Jegliche Ideen, wo Sie nachsehen müssen, wären hilfreich.

181
JeroenWyseur

Java.lang.VerifyError kann das Ergebnis sein, wenn Sie für eine andere Bibliothek kompiliert haben, als Sie zur Laufzeit verwenden.

Dies geschah zum Beispiel bei mir, als ich versuchte, ein Programm auszuführen, das mit Xerces 1 kompiliert wurde. Xerces 2 wurde jedoch im Klassenpfad gefunden. Die erforderlichen Klassen (in org.Apache.*-Namespace) wurden zur Laufzeit gefunden. ClassNotFoundException war not das Ergebnis. Es wurden Änderungen an den Klassen und Methoden vorgenommen, so dass die zur Laufzeit gefundenen Methodensignaturen nicht mit denen übereinstimmen, die sich zur Kompilierzeit befanden.

Normalerweise kennzeichnet der Compiler Probleme, bei denen Methodensignaturen nicht übereinstimmen. Die JVM überprüft den Bytecode erneut, wenn die Klasse geladen wird, und wirft VerifyError, wenn der Bytecode versucht, etwas zu tun, das nicht zulässig ist - z. Aufruf einer Methode, die String zurückgibt und diesen Rückgabewert dann in einem Feld speichert, das eine List enthält.

180
Kevin Panko

Java.lang.VerifyError sind die schlechtesten.

Sie erhalten diesen Fehler, wenn die Bytecode-Größe Ihrer Methode die 64-KB-Grenze überschreitet. aber das hättest du wahrscheinlich gemerkt.

Sind Sie zu 100% sicher, dass diese Klasse nicht im Klassenpfad an anderer Stelle in Ihrer Anwendung vorhanden ist, möglicherweise in einem anderen Glas?

Ist die Zeichencodierung der Quelldatei (utf-8?) In Ihrem Stacktrace auch richtig?

20
p3t0r

Wie Kevin Panko gesagt hat, liegt dies hauptsächlich an der Bibliotheksänderung ... __ In einigen Fällen macht ein "sauberes" Projekt (Verzeichnis) gefolgt von einem Build den Trick.

10
Flow

Ich habe diesen Fehler auf Android behoben, indem ich das Projekt erstellt habe, für das ich eine Bibliothek importiert habe, wie hier beschrieben http://developer.Android.com/tools/projects/projects-Eclipse.html#SettingUpLibraryProject)

Früher habe ich nur auf das Projekt verwiesen (es nicht zu einer Bibliothek gemacht) und diesen seltsamen VerifyError erhalten.

Hoffe es hilft jemandem.

8
Tiago

VerifyError bedeutet, dass die Klassendatei Bytecode enthält, der syntaktisch korrekt ist, jedoch gegen eine semantische Einschränkung verstößt, z. ein Sprungziel, das Methodengrenzen überschreitet.

Ein VerifyError kann grundsätzlich nur auftreten, wenn ein Compiler-Fehler vorliegt oder wenn die Klassendatei auf andere Weise beschädigt wird (z. B. durch fehlerhaftes RAM oder eine fehlerhafte HD).

Versuchen Sie, mit einer anderen JDK-Version und auf einer anderen Maschine zu kompilieren.

7

Möglicherweise versuchen Sie es mit -Xverify:all, das den Bytecode beim Laden überprüft und manchmal hilfreiche Fehlermeldungen ausgibt, wenn der Bytecode ungültig ist. 

7
Alex Miller

In meinem Fall hängt mein Android-Projekt von einem anderen Java-Projekt ab, das für Java 7 kompiliert wurde. Java.lang.VerifyError ist verschwunden, nachdem ich den Compiler-Übereinstimmungsgrad dieses Java-Projekts auf 6.0 geändert habe

Später fand ich heraus, dass dies eine Dalvik-Ausgabe ist: https://groups.google.com/forum/?fromgroups#!topic/Android-developers/sKsMTZ42pwE

5
Michal Vician

Ich bekam dieses Problem, weil pack200 eine Klassendatei mangelte. Ein bisschen Recherche hat diesen Java-Fehler nach oben gebracht. Grundsätzlich wurde durch die Einstellung von --effort=4 das Problem behoben.

Mit Java 1.5.0_17 (obwohl es in jeder einzelnen Variante von Java 1.5 aufgetaucht ist, habe ich es probiert).

4
Mike Miller

Dies kann unter Android passieren, wenn Sie versuchen, eine Bibliothek zu laden, die mit dem JDK von Oracle kompiliert wurde.

Hier ist das Problem für Ning Async HTTP-Client.

2
Martin Konicek

Ich habe ein ähnliches Java.lang.VerifyError-Problem durch Ersetzen behoben

        catch (MagickException e)

mit

        catch (Exception e)

dabei wurde MagickException in einem Bibliotheksprojekt definiert (von dem mein Projekt eine Abhängigkeit hat).

Danach habe ich einen Java.lang.NoClassDefFoundError über eine Klasse aus derselben Bibliothek erhalten (behoben gemäß https://stackoverflow.com/a/9898820/755804 ).

In meinem Fall musste ich diesen Block entfernen:

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}

Es wurde ein Fehler in der Nähe des Methodenaufrufs Fragment.showDialog() angezeigt.

2
ViliusK

Minimales Beispiel, das den Fehler generiert

Eine einfache Möglichkeit ist, Jasmin zu verwenden oder den Bytecode manuell mit einem Binärdatei-Editor zu bearbeiten.

Lasst die void-Methode ohne eine return-Anweisung erstellen (die von der return;-Anweisung in Java generiert wird), die laut JVMS illegal ist.

In Jasmin könnten wir schreiben:

.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

Dann machen wir javac Main.j und javap -v Main sagt, dass wir kompiliert haben:

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

also gibt es wirklich keine rückgabeanweisung.

Wenn wir nun versuchen, Java Main auszuführen, erhalten wir:

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)

Dieser Fehler kann in Java normalerweise nicht auftreten, da der Java-Compiler implizit return zu void-Methoden für uns hinzufügt. Deshalb müssen wir unseren return-Methoden keine main hinzufügen. Sie können dies mit javap überprüfen.

JVMS

VerifyError tritt auf, wenn Sie versuchen, bestimmte Typen illegaler Klassendateien auszuführen, wie von JVMS 7, Kapitel 4.5 angegeben.

Laut JVMS muss Java beim Laden einer Datei eine Reihe von Prüfungen durchführen, um zu prüfen, ob die Klassendatei in Ordnung ist, bevor sie ausgeführt wird.

Solche Fehler können nicht in einem einzigen Kompilierungs- und Ausführungszyklus von Java-Code generiert werden, da JVMS 7 4.10 sagt :

Obwohl ein Compiler für die Java-Programmiersprache nur Klassendateien erzeugen muss, die alle statischen und strukturellen Einschränkungen [...] erfüllen. ]

Um ein minimales Fehlerbeispiel zu sehen, müssen wir den Quellcode ohne javac generieren.

In meinem Fall hatte mein Projekt A eine Abhängigkeit von einem anderen, beispielsweise X (A verwendete einige der in X definierten Klassen). Als ich X als Referenzprojekt in den Erstellungspfad von A eingefügt habe, habe ich diesen Fehler erhalten. Als ich jedoch X als referenziertes Projekt entfernte und X's jar als eine der Bibliotheken einbezog, wurde das Problem gelöst.

1
user2484130

Diese Seite kann einige Hinweise enthalten - http://www.zanthan.com/itymbi/archives/000337.html

Es kann einen geringfügigen Fehler im Körper dieser Methode geben, den Javac nicht erkennt. Schwierig zu diagnostizieren, es sei denn, Sie posten die gesamte Methode hier. 

Sie könnten damit beginnen, so viele Variablen wie möglich als final zu deklarieren ... das hätte den auf der Zanthan-Site genannten Fehler aufgefangen und ist auf jeden Fall eine gute Praxis.

1
Lars Westergren

Wenn Sie zu Java7 migrieren oder Java7 verwenden, kann dieser Fehler im Allgemeinen angezeigt werden. Ich habe mich den obigen Fehlern gestellt und mich schwer getan, um die Ursache herauszufinden. Ich würde vorschlagen, während der Ausführung Ihrer Anwendung das Argument "-XX: -UseSplitVerifier" JVM hinzuzufügen.

1
Ulhas N

Suchen Sie nach mehreren Versionen derselben JAR-Datei in Ihrem Klassenpfad. 

Zum Beispiel hatte ich opennlp-tools-1.3.0.jar und opennlp-tools-1.5.3.jar in meinem Klassenpfad und erhielt diesen Fehler. Die Lösung bestand darin, opennlp-tools-1.3.0.jar zu löschen.

1
demongolem

Ein weiterer Grund für diesen Fehler kann die Kombination von AspectJ <= 1.6.11 mit JRE> 6 sein.

Siehe Eclipse Bug 353467 und Kieker-Ticket 307 für Details.

Dies gilt insbesondere dann, wenn auf JRE 6 alles einwandfrei funktioniert und der Umstieg auf JRE7 Probleme verursacht. 

1

Dies kann auch passieren, wenn Sie viele Module mit maven .. importieren. Es gibt zwei oder mehr Klassen mit genau demselben Namen (gleicher qualifizierter Name) .. _ und Laufzeit.

1
Toumi

CGLIB <2.2 mit JRE> 6 könnte ähnliche Fehler auslösen, siehe "Soll ich auf CGLIB 3.0 upgraden?" und einige Kommentare unter Spring SPR-9669 .

Dies gilt insbesondere, wenn auf JRE 6 alles einwandfrei funktioniert und einfach auf JRE7 umgestellt wird.

1

Java.lang.VerifyError bedeutet, dass Ihr kompilierter Bytecode auf etwas verweist, das Android nicht finden kann. Dieser verifyError gibt mich nur mit KitKat4.4 und niedrigerer Version nicht in der obigen Version aus davon lief sogar derselbe Build in beiden Devices. Wenn ich den Jackson Json Parser der älteren Version verwendet habe, wird Java.lang.verifyerror angezeigt

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.+'

Dann habe ich die Dependancy auf die letzte Version 2.2 zu 2.7 ohne die Core-Bibliothek geändert, dann klappt es. Das heißt, die Methoden und andere Inhalte von core werden auf die neueste Version von Databind2.7 migriert. Dies behebt meine Probleme.

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

bitte entfernen Sie alle unbrauchbaren JAR-Dateien und versuchen Sie es auszuführen. und seine Arbeit für mich, ich fügte eine Jcommons-JAR-Datei und auch eine andere Jcommons.1.0.14-JAR-Datei hinzu, so entfernen Sie Jcommons und seine Arbeit für mich

0
Jat Rahul

Der von Kevin genannte Grund ist zwar richtig, aber ich würde auf jeden Fall weiter unten nachschauen, bevor ich zu etwas anderem übergehe:

  1. Überprüfen Sie die cglibs in meinem Klassenpfad. 
  2. Überprüfen Sie die hibernate-Versionen in meinem Klassenpfad.

Es ist gut möglich, dass mehrere oder in Konflikt stehende Versionen der oben genannten Punkte zu unerwarteten Problemen führen können.

0
Sandeep Jindal