AbstractMethodError on Lambdas due to partial renaming of InvokeDynamic (LambdaMetafactory) call sites

[ShortyDev]

I am encountering a runtime AbstractMethodError when using Functional Interfaces that have been obfuscated/renamed by ProGuard.

Issue description & cause

The issue appears to be a desynchronization between the renamed method in the Interface definition and the name operand in the InvokeDynamic instruction. ProGuard renames the method in the interface (e.g., run -> a), but fails to update the InvokeDynamic instruction that generates the lambda.

The instruction:

invokedynamic run ()Ltest/TestFI; LambdaMetafactory.metafactory { ()Ljava/lang/String;, { invokestatic, test/Main.a, ()Ljava/lang/String; }, ()Ljava/lang/String; }

with test.TestFI being:

@FunctionalInterface
public interface TestFI {
    String a();
}

Consequently, LambdaMetafactory generates a runtime proxy class that implements the original method name, but the JVM attempts to call the obfuscated method name defined in the interface, causing a crash.

Subsequent crash

I observe the following crash at runtime:

java.lang.AbstractMethodError: Receiver class test.TestFI$$Lambda/0x0000 does not define or inherit an implementation of the resolved method 'abstract java.lang.Object a()'

Steps to reproduce & proof

1. Define a Functional Interface with a single method (e.g., execute()).
2. Use a lambda expression that implements this interface.
3. Run ProGuard with obfuscation enabled.
4. Execute the obfuscated JAR.
5. Crash: The application crashes when the lambda is invoked.

I managed to confirm this by getting it to run without any issues by manually patching the name operand in the indy instruction to match the obfuscated name.

Version info

• proguard v7.8.2 or lower (also observed with v7.7 and possibly earlier versions)
• Any Java version, used OpenJDK 64-Bit Server VM (build 24+36-3646, mixed mode, sharing) for the demonstration above.

[piazzesiNiccolo-GS]

Hi, do you have a reproducing sample/snippet? I tried this code but it works as expected:

public class App {
    public static void main(String... args) throws Throwable {
        F1 f = () -> "Hello World";
        System.out.println(f.a());
    }
}

@FunctionalInterface
public interface F1 {
    String a();
}

[ShortyDev]

Hey, thanks for looking into it.

I did it again and I'll explain what I've done step by step.
This is my original Java source code:

public static void main(String[] args) {
    Demo demo = () -> "Test ran!";
    System.out.println(demo.runTest());
}

@FunctionalInterface
public interface Demo {
    String runTest();
}

I then obfuscated the compiled jar file using ProGuard (also ensuring that the Functional Interface method got renamed from runTest to a).

Decompiled the relevant code using CFR v0.152:

private static void main() {
    a a2 = () -> "Test ran!";
    System.out.println(a2.a());
}

@FunctionalInterface
public interface a {
    public String a();
}

Using the assembler featured in Recaf 4.0.0 (5eaa2db), I looked at the invokedynamic instruction:

invokedynamic runTest ()La; LambdaMetafactory.metafactory { ()Ljava/lang/String;, { invokestatic, Main.b, ()Ljava/lang/String; }, ()Ljava/lang/String; }

runTest, which should have been renamed to a is still present with it's original name.

Now, as expected, it's throwing an AbstractMethodError when running the code with the invalid instruction:

Exception in thread "main" java.lang.AbstractMethodError: Receiver class Main$$Lambda/0x00000217a0000a18 does not define or inherit an implementation of the resolved method 'abstract java.lang.String a()' of interface a.
        at Main.main(Unknown Source)

[ShortyDev]

I have created a pull request in the core repo that resolves this issue. (Guardsquare/proguard-core#156)

The fix implements proper reference tracking for InvokeDynamicConstant, ensuring that when a Functional Interface method is renamed during obfuscation, the corresponding lambda instruction is updated to match. This fix also requires the new LambdaReferenceInitializer to be hooked up in proguard.Initializer to ensure the references are populated before renaming occurs.

[piazzesiNiccolo-GS]

Weird, I cannot reproduce with the same exact sample. In my local project, I can see the abstract method name automatically kept instead 🤔 If you can share the full reproduction project that would be quite helpful.

I will have a look at the PR by the end of the week, thanks already for looking into it.

[ShortyDev]

I'll share my config and mapping file here, I hope that is enough. Maybe I'm missing something?
Config:

-injars build.jar
-outjars test.jar
-applymapping 'map.txt'
-dontshrink
-ignorewarnings

map.txt:

proguard.issue.Main -> Main:
    void main(java.lang.String[]) -> main
proguard.issue.Main$Demo -> a:
    java.lang.String runTest() -> a

My build.jar file only contains the proguard.issue package with the relevant class files.

[piazzesiNiccolo-GS]

Weird, I tried same exact classes and configs, but the method is not renamed for me locally 🤔 Although i see this log, but it doesn't seem like it's doing anything:

Warning: com.example.App$Demo: method 'java.lang.String runTest()' is not being kept as 'runTest', but remapped to 'b'

I am using the application example project

[ShortyDev]

That is so weird. What Java and Proguard Version are you using?
It just does not work for me at all.

And I also get the same warning but I assume that's just because the mapping file enforces the mapping while there are no actual rules present that would apply to remap runTest.