Вопрос

Я исследую следующее 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 показывает ту же ошибку во время запуска сервера.

Остальная часть приложения работает нормально, только один сервлет вышел из строя.Любые идеи, где искать, будут полезны.

Это было полезно?

Решение

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

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

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

Другие советы

java.lang.VerifyError являются худшими.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я исправил аналогичную проблему 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.

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

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}

Рядом показывалась ошибка Fragment.showDialog() вызов метода.

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

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

Давайте создадим 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 говорит:

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

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

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

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

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

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

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

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

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

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

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

Видеть Ошибка затмения 353467 и Кикер билет 307 для получения подробной информации.

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

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

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

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

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

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

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

Затем я изменил зависимость на последняя версия 2.2–2.7 без основная библиотека, тогда это работает.что означает методы и другое содержимое основной переносится на последнюю версию Привязка данных2.7.Это исправит мои проблемы.

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top