Kicked from server when in certain area: com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 1

From what I've found out so far, the issue is this:

This happens when a sign is within loading distance of the player. They will be kicked. If they are not within range of a sign, they don't get kicked.

@Colm Overy: Tried that, seems to be the issue. Adjusted the debug report accordingly. Thanks!

Hi ! Yes I have the same problem when I put a sign on a wall or on the groud and after I can't access to my server and I have to take the backup I made 5 minutes before.

@unknown seems to be aware of the issue: https://twitter.com/SeargeDP/status/626414559100829696

Upgraded to 15w31b on both client and server. While there was no corresponding error in the SMP server log, the client cannot connect (see attached screen shot from 15w31b client).

load a backup, the world is probobly corrupted now

Affects 15w31b, even with a world loaded from a 1.8.8 backup.

World loaded straight from 1.8.8 still fails in 15w31b.

I've resolved this by removing all signs in the area and the problem is gone.

This issue is still relating to signs.

Had a few players on my server who's clients were crashing able to do a 180° and walk away from affected chunks by lowering their view distance to 2 and connect via slow ISP to keep affected chunks from loading while they walked away.

It seems to be 1.8.x and earlier signs causing the problems. I've had no problems with worlds with 15w31b signs, but on any world with 1.8.x or earlier signs, when converted, causes you to be unable to join the server if any of the signs are within your view distance when you spawn.

@João Not only old worlds. I created a brand new world in 15w31a for my multiplayer server and when I put a sign it corrupted the chunk.

I suspect maybe it has to do with characters that are problematic in JSON like slash (\\\\) and quotes (").

@@unknown: Please stop constantly editing your post. 13 people are receiving an email each time you do. The preview feature exists for a reason.

Sorry, I couldn't be sure that the preview was working correctly because slash it problematic in JSON (which is what these previews typically use to communicate with AJAX).

this doesn't happen for me anymore whn I open a backup that's untouched by 15w31a

I DO have this problem when updating my 1.8.8 world (server) to 15w31b..

odd that it doesn't happen at my side then

Yeah.. thats true..

Tried to reproduce the bug a few times in 15w31c, Nothing happend.

The crash still occurs on the 15w31c snapshot in a multiplayer world I generated in the snapshot. But doesn't seem to crash singleplayer worlds. I have found that the crash only occurs on servers when in range of a sign with lots of NBT data, like the ones that are created with commands and has either color or right click commands on it. Normal signs placed by hand don't crash the server. I used this command below
/setblock ~ ~1 ~ minecraft:standing_sign 0 replace {Text2:"{text:\"Test\",color:blue,bold:true,clickEvent:{action:run_command,value:\"/say Test\"}}"}
and immediately the server crashes and I get the error message in the attached screenshot.

Affects 15w31c, even with a world loaded from a 1.8.8 backup. No signs were created using commands on this world.

I think it might be signs from 1.7

Try this:

• download 1.8.8 server, make a new world

• log in, put down a sign

• log out

• load 15w31c with same world

• login

• no problems

Then:

• download 1.7.10 server, make a new world

• log in, put down a sign

• log out

• load 15w31c with same world

• login

• nope

Happened when I forst tried to join a particular server with A, was only able to join it with the b update. Now with the C update, I died and went back to my bed and I get this error now.

related to my comment above, I attached a screenshot from NBTExplorer, maybe it has to do with this? Signs in 1.7 have "null" in NBT for lines that have no text.

I can confirm my suspicions, using NBTExplorer, I searched for Signs that had 'null' instead od '""' for one of their text fields, found 2 that must have been placed in the 1.7 days. Once I removed them in 1.8.8, 15w31c lets me in no issues. Yay! This is probably just part of a larger JSON strict parsing issue.

When I join with singleplayer in the multiplayer world in front of the sign I see this (attachment)

Occurring in snapshot 15w32a

I'm sorta stuck until this is fixed. I'm kicked out immediately.

Affects 15w32a.

Can someone upload their world in which this happens?

Any world created in 1.7 that has a sign will generate this error.

Edit: this is on server

Was able to recreate the issue. World has been sent to Mojang.

Edit: Wasn't able to reproduce in singleplayer, and it doesn't kick me on 15w32a, whilst it does on 15w31a.

Investigating...

Yep, confirmed this on all my <1.7 worlds once converted to 15w32a. @unknown is there a certain site you want us to upload an example world to? Attatchments here are limited to 10mb which is far too small for any of the example worlds I have that face this issue.

Alright, can someone reproduce this with BOTH the server and the client being on 15w32a? I was unable to reproduce it once both the server and the client were updated.

Bobby: Dropbox or so would be fine, but only if it kicks you with the server updated to 15w32a.

Hello everyone..

I just wanted to let you know that i had the exact same problem with my 1.8 server.
The problem started since the first 1.9 snapshot (15w31a), and it's still there in today's snapshot (15w32a)

I can confirm this as a multiplayer (server) problem only.
The problem has everything to do with signs (from 1.7)
I have made a mcedit filter to clear all the text on signs (replace it with "text":"")
and this has completely solved the problem.

My server isn't that large so it wasn't a huge task to do this in mcedit,
but a proper solution will be better ofcourse 🙂

Yep, we have a world from 1.7.10, client gets kicked in the latest snapshot.

This occurred when we updated our server to 15w32a directly from 1.8.8, and tried to connect with 15w32a clients. Our world can be downloaded at http://wurstmineberg.de/assets/latestbackup.tar.gz (note that this is the 1.8.8 backup).

Thanks for the help tracking this down. Should be fixed the next snapshot 🙂

That is ... if my experimental code doesn't blow shit up! =D

Thank you sir! I appreciate your help on this.

Still happening to me in 15w34a. :/

@Liam: The first few snapshots completely corrupted the chunks when this bug happened. Maybe try with a new world or with a backup from 1.8 or 1.7?

I don't think that's it, cause I can still load the game in both 1.8 and 15w33b, but everything following that causes the kick. I've managed to pinpoint the source of the problem to a relatively small area near, (but not in) the spawn chunk, as being anywhere else on the server will not cause the problem. Curiously enough, (assuming my understanding is correct) it seems to also be client side, as anyone who is not within the effected area will not be kicked.

It's also worth noting that this only effects servers. Single player isn't effected at all.

Can confirm this still happens in 15w34a!

I managed to work around it on my server. At least in my case, I was able to pinpoint it down to entities within a four chunk area with meticulous strategic deletion in MCEdit. The cause was either a few stray minecarts or a cluster of item frames. Both made in 1.8 or lower. I can confirm however that again, (at least in my case) it's related to ENTITIES and not a corrupted chunk, signs, or json file somewhere.

Still happening in 15w35e. I am also pretty confident that it is entities from either 1.8, or before. This crash seems to happen for me when I import something into my world with mcedit, and I think it is either paintings, or item frames. Most likely the later.

I can say with almost 100% certainty that it is in fact item frames. As I mentioned before, it was either those or the minecarts. There was nothing else in the effected chunks. It might be worth noting that the effected item frames contain custom maps created by Img2Map, a program for essentially creating custom paintings using maps as a canvas. However, none of the other many custom maps on our server appear to be effected. Maybe a map file corruption?

I just had the same issue. I am using 15w36d on a localhost server.
For me it is definitely a sign, which is creating the issue. Though if it is placed nothing will happen. But as soon as I restart the server the chunks with signs will get corrupted and will be newly generated.
I don't know if I am doing something wrong. I am placing the signs with a commandblock:

This is the command I use:

/setblock ~ ~3 ~ minecraft:wall_sign 4 replace {Text1:"{\"text\":\"Ruhe in Frieden\"}",Text2:"{\"selector\":\"@a[score_TimeSinceDeath=0]\",\"bold\":true,\"color\":\"dark_blue\"}",Text3:"{\"text\":\"Dies ist Tod Nr.\",\"color\":\"white\"}",Text4:"{\"score\":{\"name\":\"@a[score_TimeSinceDeath=0]\",\"objective\":\"Deaths\"},\"color\":\"black\",\"bold\":true}"}

As mentioned before everything stays fine after running the command. No issues at all. But on a server restart the chunks containing the signs will be deleted.

This is the error message i get in the server console:
java -Xmx1024M -Xms1024M -jar minecraft_server.15w36d.jar nogui
[23:34:05] [Server thread/INFO]: Starting minecraft server version 15w36d
[23:34:05] [Server thread/INFO]: Loading properties
[23:34:05] [Server thread/INFO]: Default game type: SURVIVAL
[23:34:05] [Server thread/INFO]: Generating keypair
[23:34:05] [Server thread/INFO]: Starting Minecraft server on *:25565
[23:34:05] [Server thread/INFO]: Using default channel type
[23:34:05] [Server thread/INFO]: Preparing level "ServerMap"
[23:34:05] [Server thread/INFO]: Preparing start region for level 0
[23:34:06] [Server thread/ERROR]: Couldn't load chunk
java.lang.NullPointerException
at apb$1.h(SourceFile:101) ~[minecraft_server.15w36d.jar:?]
at ex.a(SourceFile:38) ~[minecraft_server.15w36d.jar:?]
at ev.a(SourceFile:31) ~[minecraft_server.15w36d.jar:?]
at apb.a(SourceFile:110) ~[minecraft_server.15w36d.jar:?]
at aok.c(SourceFile:105) ~[minecraft_server.15w36d.jar:?]
at arf.a(SourceFile:320) ~[minecraft_server.15w36d.jar:?]
at arf.a(SourceFile:81) ~[minecraft_server.15w36d.jar:?]
at arf.a(SourceFile:68) ~[minecraft_server.15w36d.jar:?]
at lk.e(SourceFile:125) [minecraft_server.15w36d.jar:?]
at lk.c(SourceFile:77) [minecraft_server.15w36d.jar:?]
at net.minecraft.server.MinecraftServer.l(SourceFile:325) [minecraft_server.15w36d.jar:?]
at net.minecraft.server.MinecraftServer.a(SourceFile:296) [minecraft_server.15w36d.jar:?]
at kv.j(SourceFile:226) [minecraft_server.15w36d.jar:?]
at net.minecraft.server.MinecraftServer.run(SourceFile:427) [minecraft_server.15w36d.jar:?]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_31]
[23:34:07] [Server thread/INFO]: Preparing spawn area: 76%
[23:34:07] [Server thread/INFO]: Done (1,417s)! For help, type "help" or "?"

Hope this is of any help.
[Erdi]

I think it's Item Frames created in past versions. Its the only thing that makes sense here. I also had items frames in the effected chunks

For me it is definitely the sign.
After the chunk was regenerated nothing was inside and I could restart the server just fine. But with the sign in it, restarting the server will result in the chunk being regenerated again. I thought it might be a user spawned bat in it but I tried it serveral times with the bat and all went fine. So I am very certain that the sign causes the problem.

I will try to recreate this on a newly generated world in 15w36d and see if signs will work. Just to be absolutely sure!

Well now it's happening for me with signs in 15w36d. Any sign placed with a command block will instantly kick me is this error.

Still present on 15w37a

I think you are experiencing MC-87281 or MC-87739.

I can't access either of those reports. o-O

They are private because they are about how you can force-kick other players by using /setblock or /give with a sign with invalid NBT data. Specifically, the first is about poorly formed JSON and the second is about leaving out lines.

Oh, so it's basically Kneeslap all over again. I had assumed that all this had been taken care of since Mojang re-enabled pickblock NBT on command blocks and signs. :/

I'm assuming then that it won't break everything if you put quotes on every single thing like the title command apparently wants?

The JSON must be formatted validly and you also need to specify that each empty line is empty.

For me the issue is now fixed in 15w39b.
Everything seems to work fine, though I am only testing a sign. I do not get any chunk errors anymore.
Thanks!

Still happens for me in 13w39c. The following command kicks the player instantly.

/setblock ~ ~-1 ~ minecraft:wall_sign 4 replace {Text1:"{\"text\":\"私の名刺に私は企業の社長です\"}",Text2:"{\"text\":\"私の心の中で私は開発者です\"}",Text3:"{\"text\":\"しかし、心で、私はゲーマーです\"}"}

It should happen with any text. This is just the one I was trying to place.

@Liam
I think you have ill-formated Json in your commandblock. In these snapshots you need to specify each line on the sign, even if they are empty: so i tried your command in 15w39b and it crashed indeed. But after adding Text4 as in the command below, everything works fine.

/setblock ~ ~-1 ~ minecraft:wall_sign 4 replace {Text1:"{\"text\":\"私の名刺に私は企業の社長です\"}",Text2:"{\"text\":\"私の心の中で私は開発者です\"}",Text3:"{\"text\":\"しかし、心で、私はゲーマーです\"}",Text4:"{\"text\":\"\"}"}

Well that I blame on MCStacker then. They've supposedly updated for the snapshots, but clearly haven't addressed everything. Still, it shouldn't cause a kick or a crash. The worst it should do is just not work and spit out the error within the console or command block. (Like the Title command for instance) If there's one thing a game shouldn't do, it's go apeshit when you input something it doesn't like. 😛