Причины получения java.lang.VerifyError

Эта страница может дать вам несколько подсказок - http://www.zanthan.com/itymbi/archives/000337.html

В теле этого метода может быть небольшая ошибка, которую javac не может обнаружить. Трудно диагностировать, если вы не разместите здесь весь метод.

Вы можете начать с объявления как можно большего количества переменных как final ... что бы отловило ошибку, упомянутую на сайте zanthan, и в любом случае это часто является хорошей практикой.

java.lang.VerifyError - худшие.

Вы получите эту ошибку, если размер байт-кода вашего метода превышает предел в 64 КБ; но вы бы наверняка это заметили.

Вы на 100% уверены, что этого класса нет в пути к классам где-либо еще в вашем приложении, может быть, в другой банке?

Кроме того, из вашей трассировки стека, является ли кодировка символов исходного файла (utf-8?) Это правильно?

Вы можете попробовать использовать -Xverify:all, который будет проверять байт-код при загрузке и иногда выдает полезные сообщения об ошибках, если байт-код недействителен.

У меня возникла эта проблема из-за того, что pack200 искажал файл класса. Немного поисков увеличил этот ошибка Java. По сути, установка --effort=4 заставила проблему исчезнуть.

Использование java 1.5.0_17 (хотя оно появлялось в каждом варианте java 1.5, в котором я его пробовал).

VerifyError означает, что файл класса содержит синтаксически правильный байт-код, но нарушает некоторые семантические ограничения, например. цель перехода, которая пересекает границы метода.

По сути, VerifyError может возникнуть только при наличии ошибки компилятора или когда файл класса поврежден каким-либо другим способом (например, из-за неисправной ОЗУ или неисправного HD).

Попробуйте скомпилировать с другой версией JDK и на другом компьютере.

java.lang.VerifyError может быть результатом, если вы скомпилировали библиотеку, отличную от используемой во время выполнения.

Например, это случилось со мной, когда я пытался запустить программу, которая была скомпилирована для Xerces 1, но Xerces 2 был найден в пути к классам. Требуемые классы (в пространстве имен org.apache.*) были найдены во время выполнения, поэтому результат ClassNotFoundException был нет. Были внесены изменения в классы и методы, так что сигнатуры методов, найденные во время выполнения, не соответствовали тому, что было во время компиляции.

Обычно компилятор помечает проблемы, в которых сигнатуры методов не совпадают. JVM снова проверит байт-код, когда класс загружен, и выдает VerifyError, когда байт-код пытается сделать что-то, что не должно быть разрешено - например, вызов метода, который возвращает String, а затем сохраняет это возвращаемое значение в поле, содержащем List.

Как сказал Кевин Панко, это в основном из-за изменения библиотеки. Так что в некоторых случаях «чистка» проекта (каталога) с последующей сборкой помогает.

Я исправил эту ошибку на Android, сделав проект, который я импортировал, библиотекой, как описано здесь http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject

Раньше я просто ссылался на проект (не превращая его в библиотеку) и получал эту странную ошибку VerifyError.

Надеюсь, это кому-то поможет.

Я исправил аналогичную проблему java.lang.VerifyError, заменив

        catch (MagickException e)

с

        catch (Exception e)

где MagickException был определен в проекте библиотеки (от которого зависит мой проект).

После этого у меня есть java.lang.NoClassDefFoundError о классе из той же библиотеки (исправлено согласно https://stackoverflow.com/a/9898820/755804).

Это может произойти на Android, когда вы пытаетесь загрузить библиотеку, скомпилированную с использованием Oracle JDK.

Вот проблема для HTTP-клиента Ning Async.

В моем случае мой проект Android зависит от другого проекта Java, скомпилированного для Java 7. java.lang.VerifyError исчез после того, как я изменил уровень соответствия компилятора этого проекта Java на 6.0.

Позже я узнал, что это проблема Dalvik: https://groups.google.com/forum/?fromgroups#!topic/android-developers/sKsMTZ42pwE

Что ж, в моем случае мой проект A зависел от другого, скажем, X (A использовал некоторые классы, определенные в X). Поэтому, когда я добавил X в качестве эталонного проекта в путь сборки A, я получил эту ошибку. Однако, когда я удалил X как упомянутый проект и включил X jar как одну из библиотек, проблема была решена.

В моем случае мне пришлось удалить этот блок:

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}

Показывала ошибку около вызова метода Fragment.showDialog().

Проверьте наличие нескольких версий одного и того же файла jar в пути к классам.

Например, у меня в пути к классам были opennlp-tools-1.3.0.jar и opennlp-tools-1.5.3.jar, и я получил эту ошибку. Решением было удалить opennlp-tools-1.3.0.jar.

Другой причиной этой ошибки может быть комбинация AspectJ <= 1.6.11 с JRE> 6.

Подробнее см. Ошибка затмения 353467 и Билет Kieker 307.

Это особенно верно, когда все работает нормально на JRE 6, а переход на JRE7 ломает работу.

CGLIB <2.2 с JRE> 6 может вызвать аналогичные ошибки, см. "Следует ли мне перейти на CGLIB 3.0?" и некоторые комментарии в Пружина SPR-9669.

Это особенно верно, когда все работает нормально на JRE 6, а простой переход на JRE7 ломает работу.

Хотя причина, упомянутая Кевином, верна, но я бы обязательно проверил ниже, прежде чем перейти к чему-то другому:

1. Проверьте cglibs в моем пути к классам.
2. Проверьте версии hibernate в моем пути к классам.

Велика вероятность, что наличие нескольких или конфликтующих версий любого из вышеперечисленных может вызвать неожиданные проблемы, подобные рассматриваемой.

Минимальный пример, который генерирует ошибку

Одна простая возможность - использовать Жасмин или вручную отредактировать байт-код с помощью редактора двоичных файлов.

Давайте создадим метод void без инструкции return (сгенерированной оператором return; в Java), что, по мнению JVMS, является незаконным.

В Jasmin мы могли написать:

.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.j, а javap -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 в обычном режиме, поскольку компилятор Java добавляет за нас неявные методы return в void. Вот почему нам не нужно добавлять return к нашим методам main. Вы можете проверить это с помощью javap.

JVMS

VerifyError возникает, когда вы пытаетесь запустить определенные типы недопустимого файла класса, как указано в JVMS 7 глава 4.5

JVMS сообщает, что когда Java загружает файл, она должна выполнить серию проверок, чтобы убедиться, что файл класса в порядке, прежде чем запускать его.

Такие ошибки не могут быть сгенерированы за один цикл компиляции и выполнения кода Java, потому что JVMS 7 4.10 говорит:

Even though a compiler for the Java programming language must only produce class files that satisfy all the static and structural constraints [... ]

Итак, чтобы увидеть пример минимального сбоя, нам нужно будет сгенерировать исходный код без javac.

Это также может произойти, если у вас много модулей, импортируемых с помощью maven. Будет два или более классов, имеющих одно и то же имя (одно и то же полное имя). Эта ошибка возникает из-за разницы в интерпретации между временем компиляции и временем выполнения.

Если вы переходите на java7 или используете java7, то, как правило, эту ошибку можно увидеть. Я столкнулся с вышеуказанными ошибками и изо всех сил пытался выяснить основную причину, я бы предложил попробовать добавить аргумент "-XX: -UseSplitVerifier" JVM при запуске вашего приложения.

java.lang.VerifyError означает, что ваш скомпилированный байт-код относится к чему-то, что Android не может найти. Это verifyError вызывает у меня только kitkat4.4 и младшая версия не в вышеуказанной версии, даже если я запускал одну и ту же сборку на обоих устройствах. когда я использовал парсер jackson 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.+'

Затем я изменил Dependancy на последняя версия с 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 и попробуйте запустить его. и его работа для меня, я добавил файл jcommons jar, а также еще один файл jcommons.1.0.14, поэтому удалите jcommons и его работу для меня

В моем случае я получал ошибку проверки с трассировкой стека ниже

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, было несоответствие в версии этой банки с той, которая поставляется с Jasper.

напишите в файл:

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

в зависимости далее: <module name = "sun.jdk"/>

После обновления Gradle в Android Studio 3.6.1 произошел сбой API 19 в сборке релиза.

Была библиотека Glideошибка. Решение - переписать proguard-rules.txt.

Также работает понижение версии Gradle (classpath 'com.android.tools.build:gradle:3.5.3'), но это устаревшее решение, не используйте его.