Obfuscation вызывает VerifyError: ожидая рамки stackmap

Мы используем последние версии JDK 7 (u45) и ProGuard версии 4.10

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

Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at
branch target 155
Exception Details:
  Location:
    com/bla/bla/service/ioc/SpringBootstrap.c()V @0: getstatic
  Reason:
    Expected stackmap frame at this location.
  Bytecode:
    0000000: b200 73b6 008b 9900 82b2 0073 b800 933b
    0000010: 1a99 0074 b200 73b6 008d 9900 6bb2 0074
    0000020: 1221 b600 cfb8 0092 4c2b b600 9c12 1db9
    ...
  Exception Handler Table:
    bci [0, 152] => handler: 155

        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
        at java.lang.Class.getMethod0(Unknown Source)
        at java.lang.Class.getMethod(Unknown Source)
        at sun.launcher.LauncherHelper.getMainMethod(Unknown Source)
        at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)

Я нашел несколько обсуждений по этой теме в StackOverflow, например

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

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

Итак, интересно, кто-то еще имел симулятивную ошибку? Или, если кто-то может даже знать конкретный способ решить эту проблему, например, отрегулировав конфигурацию proguard для процесса обфускации?

Ответ 1

Я предполагаю, что вы не указали -dontpreverify? Этот вариант почти наверняка приведет к этим ошибкам, так как он прекратит ProGuard обновлять атрибут StackMapTable. Атрибут был необязательным в Java 6, но он требуется в Java 7.

Вы все равно можете попробовать бета-версию ProGuard 4.11, но вряд ли это имеет значение здесь. Если вы напишите мне обработанный файл класса, я рассмотрю его.

(Я разработчик ProGuard)

Ответ 2

Если вы, ребята, еще не нашли решение, попробуйте проверить, есть ли у вас опция -microedition. Вот, почему это связано с StackMap. Удаление этой опции устранило эту проблему для меня.

Ответ 3

Я также столкнулся с такой же проблемой при переносе моего приложения с 1,6 до 1,7. После огромной борьбы мы нашли исправление для решения проблемы.

Подход 1: либо вы можете использовать -XX: -UseSplitVerifier аргумент разрешит эту проблему, и вам не нужно беспокоиться о обновлении файлов библиотеки.

Подход 2: Я выполнил следующие шаги, чтобы решить эту проблему. Шаг 1. Определите и сохраните список внешних библиотек, используемых вашим приложением. Шаг 2. После того, как вы идентифицируете список, продолжайте удалять по одному внешнему файлу библиотеки и подключайте обновленные файлы библиотеки версий, которые помогут вам изолировать библиотеку, которая может вызвать проблему. В моем случае: j2ee.jar и openjpa-1.2.2 файлы jar создали проблему, а затем я обновил эти библиотеки, которые разрешили проблемы с миграцией.

Следовательно, это бит медленного и болезненного процесса, чтобы выяснить, какая библиотека вызывает проблему и арестовать ее.

Надеюсь, эта информация может быть полезна, потому что она основана на моем опыте в реальном времени.