Breaking an BlockEndEye causes (irreversible) server crash

[mvdstam]

The server crashes with an "Exception while ticking a block" message. I've looked into this, and it seems that eyeBlink() (Ex-Aliquo / exaliquo / blocks / BlockEndEye.java at line 112) returns an out-of-bounds index.

A small addition: this issue only occurs on SMP, and simply placing the block in the world seems to be enough to crash the server.

[hakanai]

I discovered this just now as well, but I don't see an out of bound index. I see this:

 net.minecraft.util.ReportedException: Exception while ticking a block
     at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:663)
     at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:276)
     at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:587)
     at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:484)
     at net.minecraft.server.ThreadMinecraftServer.run(SourceFile:583)
 Caused by: java.lang.NoSuchFieldError: icon
     at exaliquo.blocks.BlockEndEye.func_71895_b(BlockEndEye.java:112)
     at exaliquo.blocks.BlockEndEye.func_71847_b(BlockEndEye.java:94)
     at net.minecraft.world.WorldServer.func_72955_a(WorldServer.java:617)
     at net.minecraft.world.WorldServer.func_72835_b(WorldServer.java:197)
     at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:657)
    ... 4 more

NoSuchFieldError means that a field which was present at compilation time is no longer present when you're running the code. Generally in normal development you get this when you compile against one version of a library and then run against another.

But I read the code here and the "icon" field it's accessing is in the same class, so I don't see how it could suddenly fail to find it. But I have seen this sort of weird thing happen when obfuscation is being used, and obfuscation is clearly being used here because the function name in the stack trace doesn't match what's in the source.

Edit: Ah, I assume this @SideOnly thing means the field gets removed from the class for the server version of the class? And then despite that, the server code is accessing the field. So that's the bug, I guess.