Wrong stack computation with (retained) dead code
Rafael Winterhalter
rafael.wth at gmail.com
Mon Aug 19 20:26:02 UTC 2024
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>
More information about the classfile-api-dev
mailing list