Chad Schaefer

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.

I absolutely disagree that this is a duplicate of MC-87041; The triggering conditions described are completely different.

Players in this instance are kicked only when commands are run. In MC-87041, no input or change needs to occur.
The errors described here are much more numerous and wide-spread than those in MC-87041.

The only duplication here is that the error triggers messages from Netty Epoll.

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.

Update: Setting a command block's command uning Blockdata also does this.

See Also MC-49761 Specifically a commandblock setting the SuccessCount on itself leads to an infinite pit of despair.

blockdata ~ ~ ~
{SuccessCount:1}

[22:05:25] Block data updated to: {Command:"blockdata ~ ~ ~ {SuccessCount:1}",id:"Control",TrackOutput:1b,LastOutput:"{"extra":[{"translate":"commands.blockdata.success","with":["{Command:\"blockdata ~ ~ ~ {SuccessCount:1}\",id:\"Control\",TrackOutput:1b,CustomName:\"@\",SuccessCount:1,z:-74,y:1,x:663,}"]}],"text":"[22:05:09] "}",CustomName:"@",SuccessCount:1,z:-74,y:1,x:663,}