StackMapTable rewriting produce invalid map when input has extended frames with an offset below 64

[sgjesse]

I ran into this issue with the following StackMapTable on input:

0, 7,                      // size
247, 0, 76, 7, 2, 206,     // same_locals_1_stack_item_frame_extended
247, 0, 63, 7, 2, 221,     // same_locals_1_stack_item_frame_extended
252, 0, 63, 7, 0, 14,      // append_frame
253, 0, 43, 7, 2, 225, 1,  // append_frame
74, 7, 0, 19,              // same_locals_1_stack_item_frame
252, 0, 23, 7, 0, 19,      // append_frame
66, 7, 2, 225              // same_locals_1_stack_item_frame

When inserting a gap in the second frame, changing the offset from 63 to 65, the frame is incorrectly rewritten, and the following StackMapTable is produced:

0, 7,                    // 7 entries
247, 0, 76, 7, 2, 206,  // same_locals_1_stack_item_frame_extended
247, 0, 65, 0,          // same_locals_1_stack_item_frame_extended
63,                     // same_frame
7,                      // same_frame
2,                      // same_frame
221,                    // ERROR!!! (position 15)
252, 0, 63, 7, 0, 14, 253, 0, 43, 7, 2, 225, 1, 74, 7, 0, 
19, 252, 0, 23, 7, 0, 19, 66, 7, 2, 225,

I think the issue lies here, where it is not taken into account that the existing encoding could already have been the extended one even with an offset below 64. As far as I can see this could happen for frame types 247 and 251.
javap will correctly disassemble the input StackMapTable, including the following frame

        frame_type = 247 /* same_locals_1_stack_item_frame_extended */
          offset_delta = 63
          stack = [ class java/lang/Exception ]

The input is produced by ASM 9.0, and for building the StackMapTable the MethodVisitor.visitFrame is used with F_NEW for all frames.

[csobrinho]

This issue has happened to us a few times with kotlin classes. Most of the times it got fixed with the new insertAfter overload with the boolean set to CtClass.isKotlin()