Weird bytecode crashing TypeAssigner?

[user-L9b40P]

I have a sample Kotlin JarFile which has some strange bytecode that is emitted which is causing issues with the TypeAssigner, causing it to crash the JVM via java.lang.OutOfMemoryError: Java heap space.

    // Byte code:
    //   0: aload_1
    //   1: ldc 'node'
    //   3: invokestatic checkNotNullParameter : (Ljava/lang/Object;Ljava/lang/String;)V
    //   6: aload_2
    //   7: ldc 'cfg'
    //   9: invokestatic checkNotNullParameter : (Ljava/lang/Object;Ljava/lang/String;)V
    //   12: aload_1
    //   13: astore_3
    //   14: iconst_1
    //   15: anewarray java/lang/String
    //   18: astore #4
    //   20: aload #4
    //   22: iconst_0
    //   23: ldc 'doRenderLayer'
    //   25: aastore
    //   26: aload #4
    //   28: astore #4
    //   30: nop
    //   31: getstatic com/gitlab/candicey/zenithcore/enum/InjectPosition.HEAD : Lcom/gitlab/candicey/zenithcore/enum/InjectPosition;
    //   34: astore #5
    //   36: iconst_0
    //   37: istore #6
    //   39: iconst_0
    //   40: istore #7
    //   42: ldc com/gitlab/candicey/crepes/hook/LayerCapeHook
    //   44: invokestatic getInternalName : (Ljava/lang/Class;)Ljava/lang/String;
    //   47: dup
    //   48: ldc 'getInternalName(T::class.java)'
    //   50: invokestatic checkNotNullExpressionValue : (Ljava/lang/Object;Ljava/lang/String;)V
    //   53: astore #8
    //   55: aload #4
    //   57: astore #7
    ...

Local variable table that I think is of interest.

31 | 297 | #4 | injectMethodName$iv | [Ljava/lang/String;

CFR decompiler creates a void variable to handle the local variable #4. Procyon fails to decompile. VineFlower decompiler is fine.

What I'm assuming is happening - but I may be wrong - is that the local #7 is being re-used across two types. At the beginning during lines 39 -> 40, it is storing iconst_0. And then later during 55 -> 57 it stores the local from #4 (An object as shown in the table).

I only assume this due to some open issues on the CFR github, which is why it produces a void type - and I assume this is causing an issue with TypeAssigner?

If this isn't an issue, is there a way to catch this or limit the TypeAssigner to prevent this crash? Many thanks.

[user-L9b40P]

As soon as I published this I remembered the LocalSplitter BodyInterceptor. By moving this above the TypeAssigner this issue is resolved. I guess my brain was one step ahead, sorry. 😓