Players get disconnected when interacting with enchanted items

[tmad40blue]

Bit of an odd one here. Players are disconnected upon right-clicking anything (even air) when an enchanted item is in their hand.

Stacktrace that's printed to Bungee's console:

17:01:14 [INFO] [tjmussrat] disconnected with: DecoderException : java.lang.UnsupportedOperationException @ io.netty.handler.codec.MessageToMessageDecoder:99
17:01:14 [INFO] [tjmussrat] -> UpstreamBridge has disconnected
17:01:14 [INFO] [tjmussrat] disconnected with: [Proxy] Lost connection to server.
17:01:14 [INFO] [tjmussrat] <-> DownstreamBridge <-> [ICmain] has disconnected
17:01:14 [SEVERE] [tjmussrat] <-> DownstreamBridge <-> [ICmain] - encountered exception
io.netty.handler.codec.EncoderException: java.lang.UnsupportedOperationException
    at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:125)
    at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:643)
    at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:700)
    at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:636)
    at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:120)
    at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:643)
    at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:700)
    at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:636)
    at io.netty.channel.DefaultChannelPipeline.write(DefaultChannelPipeline.java:944)
    at io.netty.channel.AbstractChannel.write(AbstractChannel.java:239)
    at net.md_5.bungee.netty.ChannelWrapper.write(ChannelWrapper.java:46)
    at net.md_5.bungee.connection.UpstreamBridge.handle(UpstreamBridge.java:92)
    at net.md_5.bungee.netty.HandlerBoss.channelRead(HandlerBoss.java:84)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:276)
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:263)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.handler.timeout.ReadTimeoutHandler.channelRead(ReadTimeoutHandler.java:152)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)
    at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:823)
    at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:339)
    at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:255)
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.UnsupportedOperationException
    at io.netty.buffer.PooledHeapByteBuf.memoryAddress(PooledHeapByteBuf.java:262)
    at net.md_5.bungee.jni.zlib.NativeZlib.process(NativeZlib.java:43)
    at net.md_5.bungee.compress.PacketCompressor.encode(PacketCompressor.java:42)
    at net.md_5.bungee.compress.PacketCompressor.encode(PacketCompressor.java:11)
    at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107)
    ... 36 more

[minecrafter]

Can't reproduce under current BungeeCord

[Phineas]

Is this on all your Spigot servers (the whole network)? Could we have a list of your Spigot plugins?

[tmad40blue]

@Phineas

Is this on all your Spigot servers (the whole network)? Could we have a list of your Spigot plugins?

Happens to every server on my network (3 of them). I've just disabled all plugins on all servers - completely "vanilla" Spigot and Bungee - and the exact same error persists:

23:00:31 [SEVERE] [tmad40blue] -> UpstreamBridge - encountered exception
io.netty.handler.codec.DecoderException: java.lang.UnsupportedOperationException
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:99)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:276)
    at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:354)
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:244)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.handler.timeout.ReadTimeoutHandler.channelRead(ReadTimeoutHandler.java:152)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)
    at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:823)
    at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:339)
    at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:255)
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.UnsupportedOperationException
    at io.netty.buffer.PooledHeapByteBuf.memoryAddress(PooledHeapByteBuf.java:262)
    at io.netty.buffer.SlicedByteBuf.memoryAddress(SlicedByteBuf.java:112)
    at net.md_5.bungee.jni.zlib.NativeZlib.process(NativeZlib.java:43)
    at net.md_5.bungee.compress.PacketDecompressor.decode(PacketDecompressor.java:42)
    at net.md_5.bungee.compress.PacketDecompressor.decode(PacketDecompressor.java:11)
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
    ... 19 more
23:00:31 [INFO] [tmad40blue] disconnected with: DecoderException : java.lang.UnsupportedOperationException @ io.netty.handler.codec.MessageToMessageDecoder:99
23:00:31 [INFO] [tmad40blue] -> UpstreamBridge has disconnected
23:00:31 [INFO] [tmad40blue] disconnected with: [Proxy] Lost connection to server.
23:00:31 [INFO] [tmad40blue] <-> DownstreamBridge <-> [ICmain] has disconnected

Server is running CentOS 7. I've tried with both "stable" CentOS kernel (3.10) and with a brand spankin' new kernel (4.4.0) and the error persists. LMK if I can provide any additional info.

[NickG365]

It's related to Bungee's native compression. For the time being, you can disable native compression with -Dnet.md_5.bungee.native.disable=true before -jar in the startup command.

Are you using OpenJDK or Oracle? Which version? It sounds like an OS-specific and/or implementation-specific issue.

(Edit: Added =true, didn't realize this isn't the default.)

[tmad40blue]

@NickG365

Thanks, that Java flag worked nicely - the issue is now nonexistent.

I'm using Oracle JDK 8u66 (again, on CentOS 7).

[tmad40blue]

Whoops, never mind... guess what, the issue still persists, even after disabling native compression - although now it isn't happening with only enchanted items; books are causing the same error as well.

Interestingly, the error still references Bungee's native compression, even after disabling it by adding -Dnet.md_5.bungee.native.disable to Bungee's startup command.

My Bungee startup script:

#! /bin/bash
set -o errexit

echo "Starting BungeeCord..."
java -Dname=bungee -Dnet.md_5.bungee.native.disable -d64 -server -Xms256M -Xmx2G -XX:+UseG1GC -jar BungeeCord.jar

EDIT: Actually, never mind - taking a closer look at Bungee's startup log, I'm seeing this:

00:16:52 [INFO] Could not load native library: /tmp/bungeecord-native-cipher8737730778678828294.so: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
00:16:52 [INFO] Using standard Java JCE cipher. To enable the OpenSSL based native cipher, please make sure you are using 64 bit Ubuntu or Debian with libssl installed.
00:16:52 [INFO] Using native code compressor

So despite the flag telling it not to use the native compressor, it's still doing so. Would there be any further way I could go about disabling it?

[NickG365]

Can you provide the stack trace you received with books while native compression was disabled?

[tmad40blue]

@NickG365

00:25:53 [SEVERE] [tmad40blue] -> UpstreamBridge - encountered exception
io.netty.handler.codec.DecoderException: java.lang.UnsupportedOperationException
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:99)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:276)
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:263)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.handler.timeout.ReadTimeoutHandler.channelRead(ReadTimeoutHandler.java:152)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
    at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)
    at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:823)
    at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:339)
    at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:255)
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.UnsupportedOperationException
    at io.netty.buffer.PooledHeapByteBuf.memoryAddress(PooledHeapByteBuf.java:262)
    at io.netty.buffer.SlicedByteBuf.memoryAddress(SlicedByteBuf.java:112)
    at net.md_5.bungee.jni.zlib.NativeZlib.process(NativeZlib.java:43)
    at net.md_5.bungee.compress.PacketDecompressor.decode(PacketDecompressor.java:42)
    at net.md_5.bungee.compress.PacketDecompressor.decode(PacketDecompressor.java:11)
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
    ... 18 more
00:25:53 [INFO] [tmad40blue] disconnected with: DecoderException : java.lang.UnsupportedOperationException @ io.netty.handler.codec.MessageToMessageDecoder:99
00:25:53 [INFO] [tmad40blue] -> UpstreamBridge has disconnected
00:25:53 [INFO] [tmad40blue] disconnected with: [Proxy] Lost connection to server.
00:25:53 [INFO] [tmad40blue] <-> DownstreamBridge <-> [ICmain] has disconnected

[md-5]

-Dnet.md_5.bungee.native.disable=true is required. You missed the =true

[tmad40blue]

Got it - sorry about that! Issue is now resolved after adding =true to the flag.

[md-5]

Reopening so that I can add a proper fix.

[lukalt]

I have the same issue when someone clicks a player skull or opens an inventory with skulls inside. Here is my stack trace: http://hastebin.com/berojokiyi.avrasm

Java Version: Java(TM) SE Runtime Environment (build 1.7.0_80-b15) on Debian 7

I will try starting my server with the -Dnet.md_5.bungee.native.disable=true arg again.

[ghost]

Same @lukas81298

[tmad40blue]

Can confirm that this also applies to skulls (and inventories with skulls in them).

[md-5]

Still cannot reproduce http://files.md-5.net/s/EbjJ2fT.png

[Paulomart]

Having this problem too, often when interacting with custom npcs. It happens 100% when we set the NameTag of the player in the moment the Interact Packet arrives (protocollib). Delaying the change 1 tick fixes the problem.

[Paulomart]

Also: the NameTag change needs to be done async with something like protocollib. It is not using the Bukit api. When the change is sync I'm very certain that it doesn't happen.

[ghost]

@md-5 As far as I know this happens only in external chests. Try to place/take a skull or enchanted items, you will get kicked with the error.

[md-5]

Still cannot reproduce in a chest with enchanted diamond swords.

[md-5]

Or a chest full of my own skulls

[md-5]

Cannot reproduce on CentOS 5 either.

Are you sure you aren't running any plugins? Please try on a clean server.

[NickG365]

Would be interested in seeing startup flags you all are using, too.

Can anyone find what build they were using previously where this issue didn't occur?

[kamcio96]

Mc version? Try 3 versions: 1.8 on 1.8 server 1.8 on 1.7 server with protocol hack 1.7 on 1.7 server with protocol hack

[md-5]

Only 1.8 is actually supported, don't bother if you're using anything else.

[kamcio96]

@tmad40blue @lukas81298 I cannot reproduce it too. But I'm using custom bungee version, can you test my version? removed - please don't link custom builds

[lukalt]

I was using the https://github.com/SpigotMC/BungeeCord/commit/81bd3b5f71cfed3a60176fe4a9d0d0951debc45c build before which works great. I use the -Dnet.md_5.bungee.native.disable=fals argument to start the server running the latest version of BungeeCord now and it works great. I guess that the changes from Jan 16th cause the problem.

[kamcio96]

@lukas81298 can you also test with latest version but, add -Dbungee.epoll=false argument and remove -Dnet.md_5.bungee.native.disable=false ?

[ghost]

I can confirm that this happens on 1.8.7 too. With https://github.com/SpigotMC/BungeeCord/commit/83e27f07e624bfefc9099727b55f78c4ce5534ae it works fine, but if I update anything never it happens.

[NickG365]

We're interested in seeing the startup flags (or full startup script) from anyone who's experiencing this issue to determine if they may be a factor in it.

We've narrowed down what could be causing it, but have yet to find why it's happening, nor have we been able to reproduce the issue yet.

@Aangiix3 So even build 1102 (7907610) has this issue for you?

[BoiaFaus]

Latest Arch Linux. Java 8 Players got kicked when interacting with the AAC anticheat Anti-Killaura NPC. Today AAC posted an update which fixes the problem https://gyazo.com/0ab82d938fe9b0b8d0bd36af5a6e0b65

Problem solved for me.

[VoidAngel]

Something between 4.0.31.Final and 4.0.33.Final is causing this http://pastebin.com/QhqrLwmP I ran several tests, including one using a vanilla spigot server and an unmodified Bungeecord set up. It seems interaction with anything with meta data is causing players to be kicked with the above error message. (Heads, books, banners, signs, enchantments, etc) When I use 4.0.31.Final player do not get kicked. When I use 4.0.33.Final, they do.

[kamcio96]

PlatformDependent.hasUnsafe() here BungeeCord.java#L202 should be helpful

[md-5]

@Jessicuhh13 are you saying if the only change you make is the netty version to the latest BungeeCord, this happens? What about 4.0.32?

If you want me to look at this on your server, chuck md_5@spigotmc.org an email

[VoidAngel]

@md-5 Yes the only change is the bungee version. I conducted the tests all on the same network setup. First testing vanilla with and without 4.0.33 (on its own isolated bungee server) then testing my main servers with and without 4.0.33. Then just a moment ago I tried 4.0.33 from home and it seemed to work fine... I'm going to try and narrow it down more. I'll say something if i can find what is causing this weird elusive error.

PS Ill try to find 4.0.32 and test that as well, but I'm a bit unfamiliar with how the versions are labeled on the site. I just opened op the jar to find the versions of the jars that I am currently working with.

[Black-Hole]

@Jessicuhh13 You're mixing up netty version with BungeeCord version. For the BungeeCord version run the command "bungee" on your BungeeCord console.

Anyway, running the workaround described above ("-Dnet.md_5.bungee.native.disable=true") should help with the issue.

[VoidAngel]

@Black-Hole Right, okay thank you for clearing that up for me :) I was using 1093, then updated to 1109, and that's when the problem started. That's a pretty big gap there I suppose. And the fact that I can replicate the issue on my Centos server, but not at home from my windows computer makes me think its not really bungee's problem anyways. I'll Just be quiet now xD

[tmad40blue]

@NickG365 @md-5

Bungee startup script:

#! /bin/bash
set -o errexit

echo "Starting BungeeCord..."
java -Dname=bungee -d64 -server -Xms256M -Xmx2G -XX:+UseG1GC -jar BungeeCord.jar

Spigot startup script:

#! /bin/bash
set -o errexit

echo "Starting ICmain..."
java -Dname=ICmain -d64- server -Xms256M -Xmx16G -XX:+UseG1GC -jar spigot.jar

[Janmm14]

@tmad40blue You start a BungeeCord.jar, but want to start a spigot server?

[thekeenant]

This only happens when I'm running some of the later builds of BungeeCord on CentOS 6.6. I tried locally on Windows 10 and it works fine. Adding those flags mentioned didn't change anything for me though. I know for a fact that 19f2e7b13e208e4618c5ce50bc7603c0d1515348 (jenkins build 1090) on my CentOS 6.6 worked fine, but when I upgraded to the latest the issues started occurring.

It's a bit of a different issue though: when players open a written book or some custom inventories, it instantly disconnects them with the error: http://pastebin.com/mQDM8rxX

[nikitis]

@MD_5 I opened #1729 for the same issue. I'm on centos 7. Went from 1093 bungee to 1109, and experienced the issue with player head in inventory and then accessing inventory will cause it. I back tried older bungee versions and 1105 is the highest without the problem. 1106+ has the problem. I did test removal of all plugins on bungee side, but not spigot side, but will test that and report back.

[ghost]

It would be nice if a fix could be made for this. My Hoster doesn't allow to modify startparameters, therefore to add something like: -Dnet.md_5.bungee.native.disable=false so it would be fixed :/

[md-5]

Cannot reproduce on CentOS 6.7 either. Someone affected needs to give me SSH access. Email md_5@spigotmc.org

[md-5]

@Jessicuhh13 I can't even reproduce this on your server with Vanilla. I have a BungeeCord on port 1338 and a vanilla server on port 1337. /give md_5 diamond_sword 1 0 {display:{Name:"Test Name"},ench:[{id:19,lvl:1}]}

Is the command I used

[md-5]

Nevermind, got it using skulls

[VoidAngel]

Yes, it is harder to get on vanilla, but its much worse on a server that has plugins XD On my Adventure server, almost everything you touch will kick you.

[md-5]

Resolved