Chad Schaefer
- Maxsizeis
- maxsizeis
- Europe/Stockholm
- Yes
- No
MC-49761
Was loading commandblocks in redstone chunks, loaded a particularly large command, but below the maximum limit. Each time I edited the command(s), there were several very large ones) it would kick me, AND OTHER PLAYERS within the redstone chunks off the server. I continued adding large commandblocks. At a certain point, maybe 10 large ones, I stopped being able to log in entirely as I would just keep getting kicked every "tick" with the following error: "Malformed JSON at line 1 column 1". There is no powered redstone. None of these are repeating. I just get kicked when the chunk loads after login.
At the time, I was using a bunch of "1 block installers". On retrospection, perhaps commandblock minecarts loaded with large commands (but several characters below the limit!) may be to blame? I'll have to try to recreate the scenario on a fresh backup of the map.
Was loading commandblocks in redstone chunks, loaded a particularly large command, but below the maximum limit. Each time I edited the command(s), there were several very large ones) it would kick me, AND OTHER PLAYERS within the redstone chunks off the server. I continued adding large commandblocks. At a certain point, maybe 10 large ones, I stopped being able to log in entirely as I would just keep getting kicked every "tick" with the following error: "Malformed JSON at line 1 column 1". There is no powered redstone. None of these are repeating. I just get kicked when the chunk loads after login.
At the time, I was using a bunch of "1 block installers". On retrospection, perhaps commandblock minecarts loaded with large commands (but several characters below the limit!) may be to blame? I'll have to try to recreate the scenario on a fresh backup of the map.
Researching further, I upgraded the "corrupted" map to the 34d snapshot, and the corruption still kicked me. We ran an kill @e[type=MinecartCommandBlock] , and were able to log back in no problems. So it must have something to do with the minecarts.
Additionally, running the one-block installers in survival mode in 34D I was unable to recreate the problem.
Was loading commandblocks in redstone chunks, loaded a particularly large command, but below the maximum limit. Each time I edited the command(s), there were several very large ones) it would kick me, AND OTHER PLAYERS within the redstone chunks off the server. I continued adding large commandblocks. At a certain point, maybe 10 large ones, I stopped being able to log in entirely as I would just keep getting kicked every "tick" with the following error: "Malformed JSON at line 1 column 1". There is no powered redstone. None of these are repeating. I just get kicked when the chunk loads after login.
At the time, I was using a bunch of "1 block installers". On retrospection, perhaps commandblock minecarts loaded with large commands (but several characters below the limit!) may be to blame? I'll have to try to recreate the scenario on a fresh backup of the map.
Researching further, I upgraded the "corrupted" map to the 34d snapshot, and the corruption still kicked me. We ran an kill @e[type=MinecartCommandBlock] , and were able to log back in no problems. So it must have something to do with the minecarts.
Additionally, running the one-block installers in s
urvivalmode in 34D I was unable to recreate the problem.Was loading commandblocks in redstone chunks, loaded a particularly large command, but below the maximum limit. Each time I edited the command(s), there were several very large ones) it would kick me, AND OTHER PLAYERS within the redstone chunks off the server. I continued adding large commandblocks. At a certain point, maybe 10 large ones, I stopped being able to log in entirely as I would just keep getting kicked every "tick" with the following error: "Malformed JSON at line 1 column 1". There is no powered redstone. None of these are repeating. I just get kicked when the chunk loads after login.
At the time, I was using a bunch of "1 block installers". On retrospection, perhaps commandblock minecarts loaded with large commands (but several characters below the limit!) may be to blame? I'll have to try to recreate the scenario on a fresh backup of the map.
Researching further, I upgraded the "corrupted" map to the 34d snapshot, and the corruption still kicked me. We ran an kill @e[type=MinecartCommandBlock] , and were able to log back in no problems. So it must have something to do with the minecarts.
Additionally, running the one-block installers in singleplayer creative mode in 34D I was unable to recreate the problem.
When upgrading the online server to 34d, and attempting to edit the large commandblocks again, I now get the FOLLOWING NEW ERROR
Internal exception: io.netty.handler.codec.DecoderException: java.lang.IndexOutOfBoundsException: readerIndex(1) + length(1) exceeds writerIndex(1): UnpooledHeapByteBuf(ridx: 1, widx: 1, cap: 1)
I'm spreadplayer-ing instead of teleporting myself and others 1024 blocks from spawn. I'm using the spreadplayers command like a teleport because it loads the chunk for the player so they don't glitch through things when they start.
My lobby is a large distance from my spawn chunks. It's hard to describe what happens, but:
In Spawn, Spreadplayers to an unloaded chunk far away from Spawn. Client crashes.
Relog, player position has updated and I am now standing ~1024 blocks away.
Spreadplayers BACK to spawn, which SHOULD be loaded, but doesn't have anyone in it ATM.
Client Crashes.
Relog, player position updated and am now back at spawn.
---- Minecraft Crash Report ---- // Why did you do that? Time: 9/11/15 5:18 PM Description: Unexpected error java.lang.ArrayIndexOutOfBoundsException: 16 at aqz.a(SourceFile:552) at bap.b(SourceFile:152) at bap.a(SourceFile:70) at bap.a(SourceFile:53) at bah.a(SourceFile:217) at bkp.a(SourceFile:1036) at azx.as(SourceFile:954) at azx.a(SourceFile:377) at net.minecraft.client.main.Main.main(SourceFile:125) A detailed walkthrough of the error, its code path and all known details is as follows: --------------------------------------------------------------------------------------- -- Head -- Stacktrace: at aqz.a(SourceFile:552) at bap.b(SourceFile:152) at bap.a(SourceFile:70) at bap.a(SourceFile:53) at bah.a(SourceFile:217) -- Affected level -- Details: Level name: MpServer All players: 1 total; [bkc['MaxSizeis'/1207, l='MpServer', x=1022.50, y=256.00, z=2.50]] Chunk stats: MultiplayerChunkCache: 180, 180 Level seed: 0 Level generator: ID 01 - flat, ver 0. Features enabled: false Level generator options: Level spawn location: World: (0,65,0), Chunk: (at 0,4,0 in 0,0; contains blocks 0,0,0 to 15,255,15), Region: (0,0; contains chunks 0,0 to 31,31, blocks 0,0,0 to 511,255,511) Level time: 28082603 game time, 20000 day time Level dimension: 0 Level storage version: 0x00000 - Unknown? Level weather: Rain time: 0 (now: false), thunder time: 0 (now: false) Level game mode: Game mode: creative (ID 1). Hardcore: false. Cheats: false Forced entities: 1 total; [bkc['MaxSizeis'/1207, l='MpServer', x=1022.50, y=256.00, z=2.50]] Retry entities: 0 total; [] Server brand: vanilla Server type: Non-integrated multiplayer server Stacktrace: at bid.a(SourceFile:366) at azx.b(SourceFile:2369) at azx.a(SourceFile:391) at net.minecraft.client.main.Main.main(SourceFile:125) -- System Details -- Details: Minecraft Version: 15w37a Operating System: Windows 8.1 (x86) version 6.3 Java Version: 1.8.0_51, Oracle Corporation Java VM Version: Java HotSpot(TM) Client VM (mixed mode), Oracle Corporation Memory: 116215976 bytes (110 MB) / 240504832 bytes (229 MB) up to 523501568 bytes (499 MB) JVM Flags: 6 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx512M -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:-UseAdaptiveSizePolicy -Xmn128M IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0 Launched Version: 15w37a LWJGL: 2.9.4 OpenGL: GeForce GTX 660 Ti/PCIe/SSE2 GL version 4.5.0 NVIDIA 355.60, NVIDIA Corporation GL Caps: Using GL 1.3 multitexturing. Using GL 1.3 texture combiners. Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported. Shaders are available because OpenGL 2.1 is supported. VBOs are available because OpenGL 1.5 is supported. Using VBOs: No Is Modded: Probably not. Jar signature remains and client brand is untouched. Type: Client (map_client.txt) Resource Packs: Current Language: English (US) Profiler Position: N/A (disabled) CPU: 4x Intel(R) Core(TM) i5 CPU 650 @ 3.20GHzI'm spreadplayer-ing instead of teleporting myself and others 1024 blocks from spawn. I'm using the spreadplayers command like a teleport because it loads the chunk for the player so they don't glitch through things when they start.
My lobby is a large distance from my spawn chunks. It's hard to describe what happens, but:
In Spawn, Spreadplayers to an unloaded chunk far away from Spawn. Client crashes.
Relog, player position has updated and I am now standing ~1024 blocks away.
Spreadplayers BACK to spawn, which SHOULD be loaded, but doesn't have anyone in it ATM.
Client Crashes.
Relog, player position updated and am now back at spawn.
--------------------------------------------------------------------------------------------------
Continuing with the problem.
While in
I do not seem to be kicked when I do not have my F3 coordinates on.
As soon as I toggle F3, the game crashes.
From 1024 1 0 I teleport back to 0 1 0, and toggle F3. No crash.
Telepor
---- Minecraft Crash Report ----
// Why did you do that?Time: 9/11/15 5:18 PM
Description: Unexpected errorjava.lang.ArrayIndexOutOfBoundsException: 16
at aqz.a(SourceFile:552)
at bap.b(SourceFile:152)
at bap.a(SourceFile:70)
at bap.a(SourceFile:53)
at bah.a(SourceFile:217)
at bkp.a(SourceFile:1036)
at azx.as(SourceFile:954)
at azx.a(SourceFile:377)
at net.minecraft.client.main.Main.main(SourceFile:125)A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------– Head –
Stacktrace:
at aqz.a(SourceFile:552)
at bap.b(SourceFile:152)
at bap.a(SourceFile:70)
at bap.a(SourceFile:53)
at bah.a(SourceFile:217)– Affected level –
Details:
Level name: MpServer
All players: 1 total; [bkc['MaxSizeis'/1207, l='MpServer', x=1022.50, y=256.00, z=2.50]]
Chunk stats: MultiplayerChunkCache: 180, 180
Level seed: 0
Level generator: ID 01 - flat, ver 0. Features enabled: false
Level generator options:
Level spawn location: World: (0,65,0), Chunk: (at 0,4,0 in 0,0; contains blocks 0,0,0 to 15,255,15), Region: (0,0; contains chunks 0,0 to 31,31, blocks 0,0,0 to 511,255,511)
Level time: 28082603 game time, 20000 day time
Level dimension: 0
Level storage version: 0x00000 - Unknown?
Level weather: Rain time: 0 (now: false), thunder time: 0 (now: false)
Level game mode: Game mode: creative (ID 1). Hardcore: false. Cheats: false
Forced entities: 1 total; [bkc['MaxSizeis'/1207, l='MpServer', x=1022.50, y=256.00, z=2.50]]
Retry entities: 0 total; []
Server brand: vanilla
Server type: Non-integrated multiplayer server
Stacktrace:
at bid.a(SourceFile:366)
at azx.b(SourceFile:2369)
at azx.a(SourceFile:391)
at net.minecraft.client.main.Main.main(SourceFile:125)– System Details –
Details:
Minecraft Version: 15w37a
Operating System: Windows 8.1 (x86) version 6.3
Java Version: 1.8.0_51, Oracle Corporation
Java VM Version: Java HotSpot(TM) Client VM (mixed mode), Oracle Corporation
Memory: 116215976 bytes (110 MB) / 240504832 bytes (229 MB) up to 523501568 bytes (499 MB)
JVM Flags: 6 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx512M -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:-UseAdaptiveSizePolicy -Xmn128M
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
Launched Version: 15w37a
LWJGL: 2.9.4
OpenGL: GeForce GTX 660 Ti/PCIe/SSE2 GL version 4.5.0 NVIDIA 355.60, NVIDIA Corporation
GL Caps: Using GL 1.3 multitexturing.
Using GL 1.3 texture combiners.
Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported.
Shaders are available because OpenGL 2.1 is supported.
VBOs are available because OpenGL 1.5 is supported.Using VBOs: No
Is Modded: Probably not. Jar signature remains and client brand is untouched.
Type: Client (map_client.txt)
Resource Packs:
Current Language: English (US)
Profiler Position: N/A (disabled)
CPU: 4x Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz
See Also
MC-49761Specifically 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,}
Update: Setting a command block's command uning Blockdata also does this.
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.
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.
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.