Why is the Java 7 Bytecode Verifier complaining about this Stack Frame?

Question

I have a method which I have altered in a Java 7 (major version 51) class. Using javap, I've looked at the bytecode and the Stack Frame Map. Everything looks fine:

public int addOne(int);
flags: ACC_PUBLIC
Code:
  stack=2, locals=2, args_size=2
     0: iload_1
     1: iconst_0
     2: invokestatic  #50                 // Method isSomething:(I)Z
     5: ifeq          12
     8: iconst_0
     9: goto          13
    12: iconst_1
    13: iadd
    14: ireturn

StackMapTable: number_of_entries = 2
     frame_type = 255 /* full_frame */
    offset_delta = 12
    locals = [ class test/Target, int ]
    stack = [ int ]
     frame_type = 255 /* full_frame */
    offset_delta = 0
    locals = [ class test/Target, int ]
    stack = [ int, int ]

This verifier throws this exception:

java.lang.VerifyError: Expecting a stackmap frame at branch target 12
Exception Details:
  Location:
    test/Target.addOne(I)I @5: ifeq
  Reason:
    Expected stackmap frame at this location.
  Bytecode:
    0000000: 1b03 b800 3299 0007 03a7 0004 0460 ac

What's driving me crazy is that I had the compiler generate the same code from Java source, and it looks like this:

  public int addOne(int);
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=2, args_size=2
         0: iload_1
         1: iconst_0
         2: invokestatic  #16                 // Method isSomething:(I)Z
         5: ifeq          12
         8: iconst_0
         9: goto          13
        12: iconst_1
        13: iadd
        14: ireturn

      StackMapTable: number_of_entries = 2
           frame_type = 76 /* same_locals_1_stack_item */
          stack = [ int ]
           frame_type = 255 /* full_frame */
          offset_delta = 0
          locals = [ class test/Target, int ]
          stack = [ int, int ]

Notice that the only difference in the stack frame map is that the synthetic map has all full frames -- but that shouldn't cause a difference. Does anyone know why the verfier might not like my synthetic map?

Javassist. I am using my own code to calculate the stack frame. — Charles Forsythe, Dec 22 '13 at 01:04
Everything in your synthetic stack map frame looks right to me. Maybe the issue is caused by the order of the stack map frames? If the `same_locals_1_stack_item` frame is declared *before* the full frame, I don't believe it would have locals to copy, causing that frame to be ignored and cause the error. I'm not familiar with whether or not order of the frames matters, but I'm sure it must matter to some extent for the `same_locals_1_stack_item` type to operate correctly, so it might be a stretch but try swapping the order of your stack map frames. — FThompson, Dec 22 '13 at 01:50
Or, use the stack map table generators built in to bytecode modification libraries. I've never used Javassist before, but ASM has this functionality. — FThompson, Dec 22 '13 at 01:52
I could switch to ASM, but I'm trying to get my stack frame generator to work. And yes, the order of the stack frame map entries is very important. — Charles Forsythe, Dec 22 '13 at 02:19

Antimony · Accepted Answer · 2013-12-22T15:10:40.157

I am unable to reproduce this problem. Perhaps you are creating the stack frames in a way that javap will still read but isn't actually valid? Because my edited class has the same javap output but it verifies just fine. If you post the actual classfile I can see if I can find the problem, because I don't think there's anything further I can do with just the Javap output.

Source:

public class ArrayTest {
    public int addOne(int x){
        return x + (isSomething(0) ? 0 : 1);
    }

    public static boolean isSomething(int z) {return true;}
}

Javap output of method in original class

  public int addOne(int);
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=2, args_size=2
         0: iload_1
         1: iconst_0
         2: invokestatic  #2                  // Method isSomething:(I)Z
         5: ifeq          12
         8: iconst_0
         9: goto          13
        12: iconst_1
        13: iadd
        14: ireturn
      StackMapTable: number_of_entries = 2
           frame_type = 76 /* same_locals_1_stack_item */
          stack = [ int ]
           frame_type = 255 /* full_frame */
          offset_delta = 0
          locals = [ class ArrayTest, int ]
          stack = [ int, int ]

Javap output of method in edited class

  public int addOne(int);
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=2, args_size=2
         0: iload_1
         1: iconst_0
         2: invokestatic  #15                 // Method ArrayTest.isSomething:(
)Z
         5: ifeq          12
         8: iconst_0
         9: goto          13
        12: iconst_1
        13: iadd
        14: ireturn
      StackMapTable: number_of_entries = 2
           frame_type = 255 /* full_frame */
          offset_delta = 12
          locals = [ class ArrayTest2, int ]
          stack = [ int ]
           frame_type = 255 /* full_frame */
          offset_delta = 0
          locals = [ class ArrayTest2, int ]
          stack = [ int, int ]

As you can see, I have the same Javap output, but my class works just fine.

This answer is wrong. First: the *first* frame does not have this +1 offset added. Second, the frame offsets are 12 and 0, so the two frames are at offset 12 and 13. In the compiler-generated example the code we subtract 64 from the first code to get the offset 12. If the first offset was 11, then you would get a "bad offset" exception from the verifier. — Charles Forsythe, Dec 22 '13 at 06:52
@Charles Good catch. I guess that's what I get for not testing before I post. I'll fix it. — Antimony, Dec 22 '13 at 15:07
I am accepting this answer because it highlights that what is shown by javap is hiding the real issue (see below). — Charles Forsythe, Dec 22 '13 at 22:09

Charles Forsythe · Answer 2 · 2013-12-22T22:44:51.383

The answer is that javassist sucks and I am deeply regretting using it.

The StackMapTable attribute is gotten from a call to CodeAttribute.getAttribute(String tag). Even though this is how you access it, there is no API to add it back, unless it is of type StackMapTable. The only API that accepts a vanilla AttributeInfo as a parameter is on the MethodInfo class.

In cases where the method did not need (or have) a stack frame already, you get a null. If you create an AttributeInfo structure for a new stack frame map, you shouldn't add the to the MethodInfo (where the addAttribute API is), but the CodeAttribute where it belongs.

This is what I was doing:

MethodInfo mi ...
AttributeInfo attr ...

mi.addAttribute(attr);

This is what I needed to do:

CodeAttribute ca ...
ca.getAttributes().add(attr);

(Of course, ca.getAttributes()returns an untyped List because we all miss 2004.)

I dug into the method that allows you to add a type StackFramMap to the CodeAttribute and figured out this work around for the lack of a generic API.

The result of using the top construct is that javap will make it appear that you have a proper StackMapTable. You do, but it's attached to the wrong object and you can't see that from the javap output.

I didn't use ASM for my project because I found its obsessive use of the Visitor Pattern to be annoying. I now admit that this was a bad decision. Since javassist hasn't had an update since 2012, I'm wondering if the project is dead. I certainly have a truckload of revisions I'd push. It is a mess.

EDIT Oh wow. Javassist internal code assumes that any StackMapTable attribute it its own internal StackMapTable type (because how else would you add the StackMapTable attribute). I guess I could create my own StackMapTable instance, except the SFM constructors are package protected for no apparent reason. It just gets worse and worse...

score 0 · Answer 3 · edited Jul 31 '14 at 06:56

0

http://www.csg.ci.i.u-tokyo.ac.jp/~chiba/javassist/html/javassist/bytecode/MethodInfo.html

Now you can call:

mi.rebuildStackMapIf6(pool, cf);

It will rebuild stack map, and don't use or need -XX:-UseSplitVerifier

edited Jul 31 '14 at 06:56

xav

5,452
7
48
57

answered Jul 31 '14 at 06:29

scz

1
2

That call is buggy and sometimes produces an incorrect stack frame map. That's why I was writing my own stack frame map generation in the first place. – Charles Forsythe Aug 02 '14 at 14:42

Why is the Java 7 Bytecode Verifier complaining about this Stack Frame?

3 Answers3