#458 Inconsistent stackmap VerifyError occurred with Java7


I got the following VerifyError when we start my obfuscated java application.

java.lang.VerifyError: Inconsistent stackmap frames at branch target 34 in method xxxx...

If I remove the -dontoptimize option, we don't have the problem.
And we don't have the problem with Java6.

- Proguard 4.8
- Java 1.7.0_09
- OS Mac OS X 10.8.2

Proguard option:
-renamesourcefileattribute X
-keepattributes Exceptions,SourceFile,LineNumberTable,*Annotation*
-defaultpackage ''

In addition,
If I run my application with -XX:-UseSplitVerifier option, I don't get the VerifyError.


  • Eric Lafortune

    Eric Lafortune - 2012-12-01
    • assigned_to: nobody --> lafortune
  • Eric Lafortune

    Eric Lafortune - 2012-12-01

    Could you double-check that you're _not_ specifying -dontpreverify? ProGuard's preverification step should create the correct preverification information for Java 6 (where it's optional) and Java 7 (where it's obligatory).

    Otherwise, could you mail me the class that fails?

  • dranjor

    dranjor - 2013-02-28

    I hope Toshi doesn't mind if I jump in here. I also am getting an Inconsistent stackmap VerifyError. It doesn't happen for every obfuscated method, but I narrowed it down to a small test project.

    However, I only get the exception if I refer to the obfuscated class from a JUnit test running under EclEmma. Due to that, I thought that the problem was there so filed a bug report. Having analysed the byte code, the developer said: The method a() contains a wrong stackmap frame: It misses the three local variables for this and the two parameters... The frame must read FRAME FULL [lib/MyLib J java/lang/Long] []. So I consider this as a Proguard issue.

    I have subsequently tested with proguard 4.9 beta 2 and still get the exception...

    java.lang.VerifyError: Inconsistent stackmap frames at branch target 22 in method lib.MyLib.a(JLjava/lang/Long;)V at offset 14 at app.TestApp.testApplication(TestApp.java:12) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)

    Source for MyLib.java...

    package lib;
    public class MyLib {
        public MyLib() {
            init( 1, new Long( 2L ) );
        private final void init( long i, Long l ) {
            if ( l != null ) {}

    Class file for download

    • Eric Lafortune

      Eric Lafortune - 2013-02-28

      That's a nice sample, Dranjor, thanks. As could be feared, I don't see a problem with the processed code. The stack frame for the return instruction at offset 4 says that the three only local variables become irrelevant, and that the stack is empty. This is a correct interpretation. If I create an instance of the processed class in a small test application, the JVM (1.7.0_13, IcedTea7 2.3.6) accepts it without complaining. I therefore suspect that EclEmma is instrumenting the code at run-time and introducing the verification problem.

      • dranjor

        dranjor - 2013-02-28

        Thanks Eric, I concur that running outside of Jacoco there are no problems. Equally, if I remove the -dontoptimize flag from the proguard.conf, then in this small sample the problem goes away, although it doesn't within my original library where I initially came across the problem. In that library, nothing I changed in proguard helped.

        Could you clarify what you mean by "the three only local variables become irrelevant". I won't pretend to understand the byte code at this low level. Suffice to say that my original library makes use of the variables passed into the method - it's not so devoid of code.

        Additionally, if I remove the Long from the parameters, the code runs OK under Jacoco. If I remove the test for 'l' not being null, the code also runs OK.

        • Eric Lafortune

          Eric Lafortune - 2013-03-20

          At instruction offset 4 (the return instruction), the three only local variables become irrelevant. One variable ("l") is alive during most of the method (its value is used in the condition of the if-statement), but right before the return instruction, none of the variables are alive anymore (none of their values matter anymore). The stack frames in the stack map table contain this information.

  • Eric Lafortune

    Eric Lafortune - 2013-03-20

    I see that the EclEmma project has accepted it as a bug. I'll close this one.

  • Eric Lafortune

    Eric Lafortune - 2013-03-20
    • status: open --> closed-invalid
  • Eric Gavaldo

    Eric Gavaldo - 2013-12-07

    I'm getting a VerifyError when I run my app too but it looks to me that there's anyway something wrong in proguard.

    1) I'm deploying my App as a jnlp application (no Jacoco or any other additional framework)
    2) I'm compiling using oracle's javac, not eclipse (that has a bug about it)
    2) if I don't obfuscate with proguard I don't get any VerifyError
    3) no problem either if I compile my app with Javac 1.6. The problem appears only with java7 app.
    4) important: -dontoptimize does not fix the problem!
    5) of course I'm not using -dontpreverify

    This is particularly critical as you can't provide -XX:UseSplitVerifier in a jnlp (not supported apparently in the jvm argument option).
    So basically I have currently absolutely NO workaround except removing the last feature we implemented that needs java7 and compile in java6
    I have now to delay my release supposed to happen Friday :(
    Very critical :(
    Would you have any idea or workaround?

  • Eric Gavaldo

    Eric Gavaldo - 2013-12-07

    Oh! I see this bug was closed. Sorry for that... I'm going to open a new one.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks