Wrong stack computation with (retained) dead code

[Rafael Winterhalter]

Here is a simple reproducer of this:


    ClassFile classFile =
ClassFile.of(ClassFile.StackMapsOption.DROP_STACK_MAPS);
    byte[] bytes = classFile.build(ClassDesc.of("foo.Bar"),
classBuilder -> classBuilder.withMethod(
            "foo",
            MethodTypeDesc.ofDescriptor("()Ljava/lang/Object;"),
            0,
            methodBuilder -> {
                methodBuilder.withCode(codeBuilder -> {
                    codeBuilder.ldc("x");
                    codeBuilder.areturn();
                    Label label = codeBuilder.newBoundLabel();
                    codeBuilder.ldc("x");
                    codeBuilder.ldc("x");
                    codeBuilder.areturn();
                    codeBuilder.with(StackMapTableAttribute.of(List.of(
                            StackMapFrameInfo.of(label,

List.of(StackMapFrameInfo.ObjectVerificationTypeInfo.of(ClassDesc.of("foo.Bar"))),
                                    List.of()))));
                });
            }));
    new ClassLoader() {
        @Override
        protected Class<?> findClass(String name) throws
ClassNotFoundException {
            if (name.equals("foo.Bar")) {
                return defineClass(name, bytes, 0, bytes.length);
            } else {
                return super.findClass(name);
            }
        }
    }.findClass("foo.Bar").getMethods();


Am Mo., 19. Aug. 2024 um 20:05 Uhr schrieb Rafael Winterhalter <
rafael.wth at gmail.com>:

> Hello,
>
> this is tested with a recent 24 EA.
>
> I discovered that some generated classes in Byte Buddy fail to verify
> with: Operand stack overflow - Exceeded stack size. This seems to happen
> when adding dead code, even if frames are created manually. For example, if
> I use the class file API to create the following method, I'd create the
> above verify error:
>
> String m() {
>   LDC "x"
>   ARETURN
>   F_SAME
>   LDC "x"
>   LDC "x"
>   ARETURN
> }
>
> This code might appear meaningless, but there are a bunch of code
> generators that create such weird code, that is why Byte Buddy supports it.
> It seems like the class file API computes the required stack size at 1, not
> as 2. Currently, I cannot override this.
>
> If this class is picked up by a Java agent and simply passed and returned,
> the max size will therefore decrease and the verification error will
> surface.
>
> Best regards, Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20240819/2a879e79/attachment.htm>