[MC-89127] Netty Epoll Server IO #26/ERROR

While cloning large amounts of blocks (About 4 chunks) from loaded chunks to an area around active players this causes random player disconnects.

With only one player on the server this is a non-issue.

Only affects clients when multiple are connected around the clones output area.

Server Error

[Netty Epoll Server IO #26/ERROR]: io.netty.util.IllegalReferenceCountException: refCnt: 0

Client Error

java.util.concurrent.ExecutionException: java.lang.IndexOutOfBoundsException: readerIndex(0) + length(1) exceeds writerIndex(0): UnpooledHeapByteBuf(ridx: 0, widx: 0, cap: 69888/69888)
	at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_25]
	at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_25]
	at g.a(SourceFile:46) [15w38b.jar:?]
	at bab.as(SourceFile:920) [15w38b.jar:?]
	at bab.a(SourceFile:377) [15w38b.jar:?]
	at net.minecraft.client.main.Main.main(SourceFile:125) [15w38b.jar:?]
Caused by: java.lang.IndexOutOfBoundsException: readerIndex(0) + length(1) exceeds writerIndex(0): UnpooledHeapByteBuf(ridx: 0, widx: 0, cap: 69888/69888)
	at io.netty.buffer.AbstractByteBuf.checkReadableBytes(AbstractByteBuf.java:1175) ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
	at io.netty.buffer.AbstractByteBuf.readByte(AbstractByteBuf.java:570) ~[netty-all-4.0.23.Final.jar:4.0.23.Final]
	at em.readByte(SourceFile:663) ~[15w38b.jar:?]
	at aqw.a(SourceFile:87) ~[15w38b.jar:?]
	at ard.a(SourceFile:908) ~[15w38b.jar:?]
	at bif.a(SourceFile:522) ~[15w38b.jar:?]
	at gp.a(SourceFile:68) ~[15w38b.jar:?]
	at gp.a(SourceFile:11) ~[15w38b.jar:?]
	at fh$1.run(SourceFile:13) ~[15w38b.jar:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_25]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_25]
	at g.a(SourceFile:45) ~[15w38b.jar:?]
	... 3 more

Per Lorgon111

Internal Exception: io.netty.handler.codec.DecoderException: java.lang.IndexOutOfBoundsException: readerIndix(13) + length(6684) exceeds writerIndex(13); UnpooledHeapyByteBuf(ridx: 13, widx: 13, cap: 13)

Linked issues

is duplicated by 1

MC-90165 Extra bytes in packet 32 Resolved

Comments 17

Chad Schaefer 2015-09-20T17:57:19Z

This issue only affects players at the destination end of the clone. Players far away are not effected.

The commandblocks involved execute 4 size:32K clones in one tick. The 4 clones are iterated through a much larger list several dozen times, with each clone-set happening every few ticks. These commands are repeated on a loop every 100 ticks. The destinations are all the same (a garbage region), the clones are strictly to count affected blocks over a large area.

In addition to the clones, there are a number of scoreboard operations and spread-players (to the source chunks).

A random player, usually the one connected last, is disconnected from the server when this error occurs.

DIDschl 2015-09-22T21:16:29Z

I had this issue serveral times using command blocks, even when i was cloning a small area. It also happened once while using the clone command in chat. In this case I was copying only 286 blocks. I took a screenshot of the shown error: https://www.dropbox.com/s/imhtnetytvu2uz9/Screenshot%202015-09-22%2022.58.22.png?dl=0

Michael Parker 2015-09-24T12:18:26Z

This is not a duplicate of that issue. It may be a Netty issue but not a Netty #6 error. I am on 39c now and still get this issue. You can also have more than one player on when this issue occurs.

kumasasa 2015-09-24T18:51:21Z

Relinked to MC-88016

Michael Parker 2015-09-24T18:59:52Z

This is still a different netty error and cause than 88016. I see no reason to link them.

7 more comments

kumasasa 2015-09-24T19:14:15Z

/me gives up.

Michael Parker 2015-09-24T19:18:38Z

I'm sorry. I don't mean to be a pain, but this is a specific issue. Stupidly so. Trying to bunch netty errors together makes it worse...

Brian McNamara 2015-10-03T18:02:04Z

I can also mostly-reliably reproduce this bug. The error clients see: http://i.imgur.com/ziRkdP9.png

It happens for me when I run commands to 'generate a new bingo card', which among other things, clone a bunch of pixel art (for an in-game map). So 'clone' is perhaps also implicated in my case.

It also only happens in actual multi-player (e.g. I do not repro it with two clients connected via 'Open to LAN')

Brian McNamara 2015-10-03T18:22:44Z

Hm, I managed to reproduce it once with two players in a normal survival world, with one person standing on solid ground and running

/clone ~ ~-5 ~ ~10 ~-1 ~10 ~ ~20 ~

When the bug doesn't repro, it's usually the case that only one person's client can see the cloned blocks; they're invisible to the other client until they re-log.

Brian McNamara 2015-10-07T17:42:50Z

Hm, in 41b, it has improved, but I can still repro the bug.

Here's a screenshot of a disconnected client: http://i.imgur.com/tus3sw6.png

In order to repro, I logged two people into a remote server, had them flying near one another, and had one run

/clone ~ ~-20 ~ ~10 ~ ~10 ~ ~40 ~

while near the ground. This clones some terrain up into the sky. This sometimes disconnects a player.

Brian McNamara 2015-10-07T17:48:38Z

Furthermore, any time any client reconnects, the chunk I cloned is bugged out visually until I press F3+A to reload chunks. Screenshots: http://imgur.com/a/j4N26

Brian McNamara 2015-10-07T18:04:38Z

I think one of the times it reproduced was when client A did the clone, then client B did an F3+A to reload chunks, and it disconnected client A at that moment. (Might it be sending chunk update packets to the wrong client?) Haven't been able to reproduce that yet, but the DC is not always 'time-immediate' with the clone, it seemed like at least one was instead time-immediate to another client doing F3+A

Fenhl (Max Dominik Weber) 2015-10-08T02:00:37Z

this is a duplicate of MC-87041, but that one has been erroneously marked as fixed.

Michael Parker 2015-10-08T02:04:01Z

We've fought about the Netty Error 6/26 distinction. They are different issues, thus the different error codes...

Also this kicks randomly. First, last, any in between. It doesn't favor the first in.

Fenhl (Max Dominik Weber) 2015-10-08T02:18:24Z

Same with the other one. And the part before the slash in the server logs is just the origin thread.

Michael Parker 2015-10-08T02:30:20Z

The "readerIndix(17)" on the other error is different than this which returns "readerIndix(13)" errors which is also a is a different index. They are separate issues.

Chad Schaefer 2015-10-09T02:39:23Z

Parkervcp and I have been testing if this error has been resolved. Work has been done on it, for sure. There must be more than one error involved here, because the overall problem still exists, but we're getting different error codes now.