ASM cannot read class with out-of-bounds annotation type

[Janmm14]

Seems to load fine in jvm (loaded via -cp and tried as main class, error is not could not read class, but couldnt find main) For recaf, the class net.minecord.dualwielding.controller.DualWieldingController in not a class, but listed under files Jar file in question: https://www.spigotmc.org/resources/dualwielding-fighting-with-two-hands-supporting-placeholderapi-bungeecord-compatibile.60894/

[Col-E]

The class has invalid try catch annotations inside methods like onPlayerInteractEvent(Lorg/bukkit/event/player/PlayerInteractEvent;)V.

// CP
  #200 = Utf8               Lorg/jetbrains/annotations/NotNull;

// Method
      Exception table:
         from    to  target type
           141   232   236   Class org/bukkit/plugin/AuthorNagException
           141   232   236   Class java/lang/IllegalArgumentException
           141   232   236   Class java/lang/NullPointerException
      RuntimeInvisibleTypeAnnotations:
        0: #200(): LOCAL_VARIABLE, {start_pc=15, length=357, index=2}
        1: #200(): EXCEPTION_PARAMETER, exception_index=65535         <---------------------- Problem
        2: #200(): LOCAL_VARIABLE, {start_pc=299, length=72, index=3}

In Cafedude:

So it looks like the NotNull annotation is messing things up. I'm thinking this is probably an automated process thats busted. Maybe IntelliJ uses this value internally and doesn't care that the index is bogus? Honestly I'd report this upstream to them too.

[Col-E]

Currently Cafedude strips attributes in terms of CP access violations. This will require some reworking so it can access other attributes. Shouldn't be too crazy to allow dropping or modification of these values.

[Col-E]

If you don't mind @misuda12 since this is a plugin you made, what IntelliJ version are you running? And did you add the @NotNull annotation yourself to the exception type? Is there a plugin to automatically add @NotNull that you're using?

I can't seem to re-create a sample that has this problem after an hour of trying :/

I've tried putting @NotNull in a variety of combinations similar to what the decompiled code shows.... and nothing recreates it.

[Janmm14]

https://gitlab.ow2.org/asm/asm/-/issues/317953

[Col-E]

IntelliJ support chimed in and said it doesn't look like something that belongs to their instrumentation.

hello, from our side we don't see any traces of IDEA's @NotNull instrumentation being applied to the code - no parameter check, no $$$reportNull$$$ method. If possible sample repro would really help to understand the issue. Thank you

https://gitlab.ow2.org/asm/asm/-/issues/317953

Remi Forax: One interesting question is how this classfile was produced, because there is maybe a bug in javac or an other library used to create that class.

Still waiting on misuda12 for a response.

[misuda12]

Hello :) I'll look at the problem asap, hence I have abandoned this project since 1.14+ As far as I know, it was badly compiled since annotations used, were outdated and I've also used some of em in the wrong place. There should be an update to fix this in few hours, if I'll find source I've used 😳

[misuda12]

I guess the problem was that Ive used @NotNull in the catch block, which has no purpose, well, I've been learning Java that time

[Col-E]

Right, but when I try to compile the following:

try  {
    System.out.println(test.concat("!"));
} catch (@NotNull IndexOutOfBoundsException | NumberFormatException | NullPointerException e) {
    System.err.println("Error (" + e.getMessage() + ")");
}

It compiled correctly.

// Only applied to the first exception type, and the index is correct
      RuntimeInvisibleTypeAnnotations:
        0: #66(): EXCEPTION_PARAMETER, exception_index=0

I'm using Maven 3.8 / Java 8 to compile this sample. I'm not sure how your plugin made the index into 65535 (0xFFFF)

[Col-E]

The recent refactoring in 346016df79acae5f7433f594f01079a2a802f598 should make everything accessible to the patching routine that is needed to check for index validation. I'll get on that later though.

[Col-E]

Well, however this was made (still a mystery, cannot reproduce) 799a4f300799682d31cc0c57e60a9aa3ea64e7c8 supports tossing invalid type-annotations based on target-paths.