java.lang.VerifyError: Operand stack underflow when multiple redirector injectors target the same opcode

[Barteks2x]

When updating to forge 1.9.4 my ChunkCache mixin caused VerifyError, this is the smallest Mixin that still causes it:

@Mixin(ChunkCache.class)
public abstract class MixinChunkCache {
    @Redirect(method = "getBlockState", at = @At(value = "INVOKE", target = "Lnet/minecraft/util/math/BlockPos;getY()I"))
    public int getPosYOverride(BlockPos pos) {
        return pos.getY();
    }
}

And here is the whole error: http://pastebin.com/Kp1Pe83N

[Mumfrey]

Thanks for the report, I will look into it and see what's going on.

[Mumfrey]

I can't reproduce this in vanilla with your test code so I guess some change that forge is making is the cause of the issue. I guess I will have to set up a forge workspace to test this out so it'll take a bit longer to investigate.

[Barteks2x]

It turns out it was my own mistake. I was redirecting BlockPos.getY ffrom that method from 2 different mixins. I asked on #spongedev before reporting it and I was told to report it here. Sorry for confusion. I should have disabled all other mixins before reporting anything.

In 1.9 there was getBlockStateRaw method in RegionRenderCache, but in 1.9.4 this class wasn't there. So I moved the redirect from RegionRenderCache to client version of ChunkCache mixin. But there was already the same redirect in common version of ChunkCache mixin.

[Mumfrey]

Redirectors are actually supposed to detect that kind of thing though, so it's kind of still a bug. In a nutshell if a redirector from one mixin "claims" a particular opcode, then only a mixin with a higher priority should be able to "claim" that same opcode and redirect it. This is part of the design which is there to ensure that multiple mixins can safely target the same classes and the priority semantics then determine the winners.

Basically, if this mechanism is not functioning as intended then it's still a bug, albeit a different bug to the one you were anticipating. I will investigate further.

[Mumfrey]

I have tracked down the problem, thanks for reporting this, it means I can push a fix and next time you'll get a sensible error instead of a corrupted class file.