java.lang.VerifyErrorを取得する原因


191

私は以下を調査しています 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)

これは、サーブレットがデプロイされているjbossサーバーが起動したときに発生します。これはjdk-1.5.0_11でコンパイルされており、jdk-1.5.0_15で再コンパイルしようとして成功しました。つまり、コンパイルは正常に実行されますが、デプロイされると、java.lang.VerifyErrorが発生します。

メソッド名を変更して次のエラーが発生した場合:

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)

メソッドシグネチャがさらに表示されていることがわかります。

実際のメソッドシグネチャは

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

私はすでにそれを見てみましたがjavap、それはあるべき方法でメソッドのシグネチャを与えます。

他の同僚がコードをチェックアウトし、コンパイルしてデプロイすると、同じ問題が発生します。ビルドサーバーがコードを取得して開発環境またはテスト環境(HPUX)にデプロイすると、同じエラーが発生します。また、Ubuntuを実行している自動テストマシンでも、サーバーの起動時に同じエラーが表示されます。

アプリケーションの残りの部分は問題なく実行され、その1つのサーブレットだけが故障しています。どこを見るかについてのアイデアは参考になります。


1
私は、ComparisonFailureの間違ったバージョンを使用してそれを取得しました。FOREVERを見つけるために取りました...それは苦痛でした
Tim Boland

1
Androidスタジオでインスタントラン(コンパイル時にホットスワッピング)を使用するときに取得しました。それをオフにすることは仕事をしました。
セルジュ

回答:


188

java.lang.VerifyError 実行時に使用しているのとは異なるライブラリに対してコンパイルした場合に、結果が生じる可能性があります。

たとえば、Xerces 1に対してコンパイルされたプログラムを実行しようとしたときにこれが起こりましたが、Xerces 2がクラスパスで見つかりました。(で必要なクラスorg.apache.*の名前空間)は、実行時に発見された、そうClassNotFoundExceptionだったではありません結果。クラスとメソッドに変更があったため、実行時に検出されたメソッドシグネチャは、コンパイル時に存在したものと一致しませんでした。

通常、コンパイラーは、メソッドのシグニチャーが一致しない問題にフラグを立てます。JVMは、クラスがロードされたときに再びバイトコードを確認し、スローされますVerifyErrorバイトコードは許されるべきではない何かをやろうとしているとき-例えばメソッドを呼び出すと、その戻りString、その後、店舗その保持しているフィールドの戻り値がList


3
追加すべきことの1つは、IDEの障害、またはバイトコードが正しくないデバイスである場合があります。IDEを再起動して、同期の問題を認識させます。それが失敗した場合、アプリを削除して再インストールします。デバイスを再起動すると問題が解決する場合があります。
ima747 2014

2
どのクラスが原因であるかを確認するには、VM引数-verbose:classを追加し、ロードする直前にクラスを探しますjava.lang.VerifyError。これはJARへのパスになります。これを使用javapして、コンパイル対象のクラスと比較します。エラーで報告されたクラスが実際には引数の1つである原因ではなかったため、これは有用であることがわかりました。
steinybot

21

java.lang.VerifyError 最悪です。

メソッドのバイトコードサイズが64kbの制限を超えると、このエラーが発生します。しかし、おそらくあなたはそれに気づいたでしょう。

このクラスがアプリケーションの他の場所、おそらく別のjarのクラスパスに存在しないことを100%確信していますか?

また、スタックトレースから、ソースファイルの文字エンコーディング(utf-8?)は正しいですか?


きっと他の場所には存在しないと思います。それは43Kbであり、それはまだ大きなクラスです。
Jeroen Wyseur 2008

その投稿をありがとう、私の場合、それは別のエンコーディングでした:JasperReports XMlファイルはエンコーディングとJavaバージョンを保存します。これをプロジェクト設定に応じて(iReportを介して)設定する必要があります。それがここでの問題でした、エンコーディングに関するあなたの考えに感謝します!:)
トビアス

これはAndroidテストの私の問題で、マルチデックスで修正しました。
Prakash Nadar 2018

10

Kevin Pankoが言ったように、それは主にライブラリの変更が原因です。したがって、場合によっては、プロジェクト(ディレクトリ)を「クリーン」にした後にビルドを行うとうまくいきます。


9

あなたが試すかもしれないことの一つは、使用している-Xverify:all負荷にバイトコードを検証なるとバイトコードが無効である場合、時には便利なエラーメッセージを与えます。


8

ここで説明するように、私は、私は、ライブラリをインポートしたプロジェクトを作ることによってAndroid上でこのエラーを修正http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject

以前は、プロジェクトを参照しているだけで(ライブラリではありません)、この奇妙なVerifyErrorが発生していました。

それが誰かを助けることを願っています。


2
リンクは使用できなくなりました。修正してください。感謝
Mahdi Rashidi 2016年

8

VerifyErrorは、クラスファイルに構文的には正しいが、メソッドの境界を越えるジャンプターゲットなどの意味上の制限に違反するバイトコードが含まれていることを意味します。

基本的に、VerifyErrorが発生するのは、コンパイラのバグがある場合、またはクラスファイルが他の方法(RAMの不良やHDの障害など)で破損した場合のみです。

別のJDKバージョンで、別のマシンでコンパイルしてみてください。


5

私の場合、私のAndroidプロジェクトはJava 7用にコンパイルされた別のJavaプロジェクトに依存しています。 java.lang.VerifyErrorそのJavaプロジェクトのコンパイラコンプライアンスレベルを6.0に変更した後、消えました

後で私はこれがDalvikの問題であることを知りました:https : //groups.google.com/forum/? fromgroups#!topic/android-developers/ sKsMTZ42pwE


1
DalvikはJava6の分岐バージョンなので、Java7機能は使用できません。
Jeroen Wyseur 2013年

4

pack200がクラスファイルを変換するため、この問題が発生しました。少し検索すると、このJavaバグが発生しました。基本的に、設定--effort=4により問題は解消されました。

java 1.5.0_17を使用しています(ただし、私が試したjava 1.5のすべてのバリアントで発生しました)。


3

置き換えることにより、同様のjava.lang.VerifyErrorの問題を修正しました

        catch (MagickException e)

        catch (Exception e)

どこ MagickExceptionライブラリプロジェクト(プロジェクトが依存しているプロジェクト)で定義された。

その後java.lang.NoClassDefFoundError、同じライブラリからクラスを取得しました(https://stackoverflow.com/a/9898820/755804に従って修正されました)。


1
これは私にとってはうまくいきました...「私を全面的な例外に置き換えて、私は仕事をします」以外にもエラーが何であったかを本当に知りたいのですが。
Alex Hart

@AlexHartそれは、Androidのためだが、おそらく同じロジックは、エンタープライズJavaのために適用されます:stackoverflow.com/a/36814155/253468
TWiStErRob


2

私の場合、このブロックを削除する必要がありました:

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}

Fragment.showDialog()メソッド呼び出しの近くでエラーが発生していました。


2

エラーを生成する最小限の例

単純な可能性の1つは、Jasminを使用するか、バイナリファイルエディターでバイトコードを手動で編集することです。

JVMが違法であると言う(Java のステートメントによって生成されvoidた)return命令のないメソッドを作成return;してみましょう。

ジャスミンでは次のように書くことができます:

.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

次に、コンパイルして完了したjavac Main.jjavap -v Main言います。

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

ですから、実際には返品の指示はありません。

実行しようとすると、次のようjava Mainになります。

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)

Javaコンパイラーがメソッドに暗黙returnを追加するため、このエラーはJavaでは通常発生しませんvoid。これがreturnmainメソッドにを追加する必要がない理由です。あなたはこれをチェックすることができますjavapます。

JVMS

VerifyErrorは、JVMS 7の第4.5章で指定されている特定のタイプの不正なクラスファイルを実行しようとすると発生します。

JVMSは、Javaがファイルをロードするとき、クラスファイルを実行する前に、一連のチェックを実行してクラスファイルに問題がないことを確認する必要があると述べています。

JVMS 7 4.10によると、このようなエラーは、Javaコードの1回のコンパイルおよび実行サイクルでは生成できません。

Javaプログラミング言語用のコンパイラは、静的および構造上のすべての制約を満たすクラスファイルのみを生成する必要がありますが[...]

したがって、最小限の失敗の例を確認するには、なしでソースコードを生成する必要がありますjavac


1

このページはいくつかのヒントを与えるかもしれません-http ://www.zanthan.com/itymbi/archives/000337.html

そのメソッドの本体にjavacが見つけられない微妙なバグがあるかもしれません。ここにメソッド全体を投稿しないと、診断が困難です。

できるだけ多くの変数をfinalとして宣言することから始めることができます。これは、zanthanサイトで言及されているバグをキャッチすることになるため、とにかく多くの場合良い方法です。


1
その男は2002年にコンパイラのバグを直撃しましたが、そのバグはそれ以来修正されています。
Kevin Panko

1

よく私の場合、私のプロジェクトAは別のものに依存していました、たとえばX(AはXで定義されたクラスのいくつかを使用していた)。Aのビルドパスに参照プロジェクトとしてXを追加すると、このエラーが発生しました。ただし、参照プロジェクトとしてXを削除し、ライブラリの1つとしてXのjarを含めると、問題は解決しました。


1

クラスパスで同じjarファイルの複数のバージョンを確認してください。

たとえば、クラスパスにopennlp-tools-1.3.0.jarとopennlp-tools-1.5.3.jarがあり、このエラーが発生しました。解決策は、opennlp-tools-1.3.0.jarを削除することでした。




1

また、Mavenで多数のモジュールをインポートしている場合にも発生する可能性があります。まったく同じ名前(同じ修飾名)を持つ2つ以上のクラスが存在します。このエラーは、コンパイル時と実行時の解釈の違いが原因です。


1

java7に移行している場合、またはjava7を使用している場合は、通常、このエラーが発生する可能性があります。上記のエラーに直面し、根本的な原因を見つけるために多くの苦労をしました。アプリケーションの実行中に「-XX:-UseSplitVerifier」 JVM引数を追加してみることをお勧めします。


1

Android Studio 3.6.1で更新Gradleした後、リリースビルドのAPI 19でクラッシュが発生しました。

あったGlideライブラリエラーが。解決策は、proguard-rules.txtを書き換えることです

ダウングレードもGradle機能します(classpath 'com.android.tools.build:gradle:3.5.3')が、これは古いソリューションなので、使用しないでください。


0

ケビンによって述べられた理由は正しいですが、私は何か他のものに移動する前に必ず以下をチェックします:

  1. cglibsクラスパスで確認してください。
  2. hibernateクラスパスのバージョンを確認してください。

上記のいずれかの複数のバージョンまたは競合するバージョンがあると、問題のような予期しない問題が発生する可能性があります。


0

java.lang.VerifyErrorは、コンパイルされたバイトコードがAndroidが見つけられないものを参照していることを意味します。このverifyError は、両方のデバイスで同じビルドを実行したとしても、上記のバージョンではなく、kitkat4.4以下のバージョンでのみ問題を引き起こします。古いバージョンのジャクソンjsonパーサーを使用すると、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.+'

次に、依存関係をコアライブラリなしの最新バージョン2.2から2.7に変更しました。これは、メソッドとコアの他のコンテンツが最新バージョンのDatabind2.7に移行されることを意味します。これは私の問題を修正します。

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

どのJARを探すべきかをどうやって知るのですか?
Siddharth、2017

1
jackson-core:2.2。+はレガシーになりました。したがって、databind:2.7.0-rc3、annotations:2.7.0-rc3、またはこれよりも新しいバージョンを使用する必要があります。これは2つで十分です。jackson-core:2.2。+は避けてください。その時までにいくつかのverifyerrorを得ました。2.7以降のバージョンを使用している間は、そのエラーは表示されません
anand krish

0

使用できないjarファイルを削除して実行してください。そして私のためのその仕事私はjcommons jarファイルとまた別のjcommons.1.0.14 jarファイルを追加したのでjcommonsと私のためにその仕事を削除します



-1

私の場合、以下のスタックトレースで検証エラーが発生していました

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)

commons-codec-1.3.jarのクラスパスエントリを削除して解決しました。このjarのバージョンとJasperに付属するjarのバージョンが一致していませんでした。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.