Obfuscation causes VerifyError: Expecting a stackmap frame - obfuscation

Question

We are using latest JDK 7 (u45) and ProGuard Version 4.10
Lately starting our distribution fails, after obfuscating it, with the following error:
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)
I found several discussions about this topic on StackOverflow, like
java-lang-verifyerror-expecting-a-stackmap-frame-at-branch-target-jdk-1-7
java-lang-verifyerror-expecting-a-stackmap-frame
understanding-how-to-resolve-inconsistent-stackmap-frames-exception
java-7-inconsistent-stackmap-frames-need-help-understanding-why-solution-wor
From what I understood is, that java 7 uses a stricter verification and introduced a stack map for classes to verify the code. So somehow during my obfuscation process this map seems to get corrupted, since only this exception occurs, when I obfuscate my project with proguard.
Disabling the verification with -XX:-UseSplitVerifier and starting the builded jar helps, but im not really sure if that should be the way handling this issue.
So I wonder if anyone else had a simular error? Or if anyone might even knows a specific way to solve this, for example by adjusting the proguard konfiguration for the obfuscation process?

Answer 1

I assume you are not specifying -dontpreverify? That option will almost certainly lead to these errors, since it will stop ProGuard from updating the StackMapTable attribute. The attribute was optional in Java 6, but it is required in Java 7.
You could still try a beta version of ProGuard 4.11, but it is unlikely that it makes a difference here. If you mail me the processed class file, I'll look into it.
(I am the developer of ProGuard)

Answer 2

In case you guys didn't find a solution yet, you may try to check if you have -microedition option. Here's why it related to StackMap. Removing this option fixed this issue for me.

Answer 3

I also faced the same challenge when migrating my application from 1.6 to 1.7. After huge struggle, we found a fix to address the issue.
Approach 1: Either you can use -XX:-UseSplitVerifier argument will resolve this issue and you don't need to worry about to upgrade the library files.
Approach 2: I have followed the below steps to overcome the issue. Step 1: Identify and keep a list of external libraries consumed by your application. Step 2: Once you identify the list, keep removing one by one external library files and plug in upgraded version library files which will help you to isolate the library which might causing the issue. In my case: j2ee.jar and openjpa-1.2.2 jar files created an issue and then I have upgraded these libraries which had resolved the migration issues.
Hence, It is bit of slow and painful process to figure out which library causing the issue and arrest it.
I hope, this information might be useful because it is based out of my real time experience.