15

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

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?

Community
  • 1
  • 1
crusam
  • 6,140
  • 6
  • 40
  • 68

3 Answers3

30

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)

Eric Lafortune
  • 45,150
  • 8
  • 114
  • 106
  • Thanks for your answer Eric. This indeed was the mistake. We used the -dontpreverify attribute in our konfiguration. I am just wondering, that it was working in 4.7 (together with Java 7) even with that property. Only upgrading to 4.10 revealed this mistake. Activating this property fixed it and our Server-Component is working fine again. – crusam Nov 13 '13 at 11:29
  • Unfortunatly now our Client throws a different kind of Error: Unexpected problem on thread AWT-EventQueue-0: '''Inconsistent stackmap frames at branch target 64'''. Do you may have any leads what might causes that? Is there still something else, I have to consider with configurating ProGuard for Java7? – crusam Nov 13 '13 at 11:32
  • It sounds like the same problem -- don't use -dontpreverify for your client application. – Eric Lafortune Nov 14 '13 at 21:06
  • We made sure, its not used for the client application (server and client are obfuscated with same configuration). And the Error is slightly different since it now says 'inconsistent stackmap' instead of 'expecting a stackmap'. I understand why the map might be missing (-dontpreverify) but what might could cause an inconsistency stackmap error? – crusam Nov 14 '13 at 21:28
  • If you mail me the processed class file that fails, I'll look into it. – Eric Lafortune Dec 03 '13 at 21:28
  • 1
    hello eric, sorry that I did not reply to your generous offer to check our file, but I havent noticed, that you replied here again. Just wanted to mention, that we looked into this topic again and found the following bugticket in proguard, which solved our issue: http://sourceforge.net/p/proguard/bugs/498/ . Thank you again and keep on the good work, especially since you are very busy. We are looking forward to a future java 8 support. – crusam Apr 03 '14 at 14:51
  • You saved my day! :-) – DKIT Aug 13 '15 at 22:25
0

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.

desertkun
  • 1,027
  • 10
  • 19
0

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.

SaravanaC
  • 81
  • 1
  • 3