[MC-30940] Game crashes and deletes chunks when encountering invalid items, such as lit Redstone Lamps broken with Silk Touch

When the game encounters an unrecognized or "invalid" item ID, it reacts by crashing and often deleting the chunk which contained the item. Invalid item IDs can be created in a number of ways, including breaking lit redstone lamps with a Silk Touch enchantment, or loading a world from a version where these IDs are considered valid.

Steps to Reproduce:
1. Place a redstone lamp, and power it.
2. In survival, break the lamp with a Silk Touch tool.
3. Observe that the game crashes, and when you reload the world, the chunk will be regenerated (all player-made structures removed, and all mined ores respawned).

Alternate Steps to Reproduce:
1. Load up a world in Minecraft 1.6.2.
2. Type "/give @p 75" (you must have Cheats enabled)
3. Observe that you are given an unlit redstone torch. It seems to work perfectly fine as an item when held, placed in a chest, mounted in an item frame, or placed as a block. No crashes occur.
4. Place the torch in a chest, and save/exit the world.
5. Load the world in 13w37a.
6. Observe that the entire chunk containing the chest has been refreshed.

Linked issues

is duplicated by 2

MC-31470 Breaking an ON redstone lamp with Silk touch will CRASH the GAME Resolved

MC-33748 /give block 34 causes crash and chunk corruption/deletion/regeneration Resolved

Attachments

crash-2013-09-12_19.54.24-client.txt

crash-2013-09-13_04.35.24-client.txt

Comments 20

D. Morrell 2013-09-13T03:01:44Z

It says my "Game may be modded, and as such [they] can't accept [the] crash report."

Hogwash! Hogwash, I say!

Edit: Can't get chunk deleted in SSP, even after 3 attempts. The game crashed all three times, and it lied about mods all three times, too.

Zuriki 2013-09-13T03:41:51Z

I can confirm. Just to specify, must be done in survival mode - not creative mode.

However my crash dump detects the client as vanilla just fine, unlike the above comment.

Edit: Attached crash dump to confirm,

Zuriki 2013-09-13T03:43:14Z

Zuriki - Crash dump confirmation

kumasasa 2013-09-13T05:36:37Z

Duplicate of MC-3973

Zuriki 2013-09-13T06:30:41Z

This is NOT a duplicate. The item is not retrieved, it causes a CRASH and CHUNK ERROR. Duplicate link says item enters inventory with NO CRASH.

One is harmless, this is a severe crash. Please reverse the duplication link.

10 more comments

kumasasa 2013-09-13T06:41:53Z

Your crash:

Description: Rendering entity in world
java.lang.NullPointerException
	at zf.d(SourceFile:104)
	at bjq.a(SourceFile:148)
	at bjq.a(SourceFile:29)
	at bjg.b(SourceFile:35)
	at bjq.a(SourceFile:45)

crash of MC-3973:

Description: Rendering entity in world
java.lang.NullPointerException
	at zf.d(SourceFile:104)
	at bjq.a(SourceFile:148)
	at bjq.a(SourceFile:29)
	at bjg.b(SourceFile:35)
	at bjq.a(SourceFile:45)
	at bjq.a(SourceFile:29)

WolfieMario 2013-09-13T13:49:19Z

The bug here is that 13w37a's changes to the world format have made the game react very poorly when it encounters an unknown item. It has also made "lit redstone lamp" become invalid as an inventory item. So, MC-3973 is a bug where you're able to obtain lit redstone lamps in item form. The new bug is that this can cause entire chunks to be deleted.

Shall I report this as a new ticket? Chunk deletion is not a rendering issue, and is new to 13w37a. I don't see how that can be a duplicate of any bug prior to 13w37a. I've already lost many chunks in old worlds thanks to it - this chunk deletion issue is not in any way limited to redstone lamps.

lapppy 2013-09-13T17:28:35Z

That crash from MC-3973 is unrelated to the original bug report, which was:

Not sure if this is intended or not, but when you use Silk Touch tools on a redstone lamp that is lit, it occupies a separate inventory slot, with a lit-up graphic.

Unless my eyes fail me, I believe that there is no mention of a crash there, and no mention of world corruption either.

So, this report should either be reopened or MC-3973 should be updated completely to reflect the new crash (Not just the title).

kumasasa 2013-09-13T20:06:32Z

Reopened, did misread MC-3973.

Zuriki 2013-09-13T20:26:37Z

Thank you, Kumasasa, you are forgiven for your past transgressions. 😉

WolfieMario 2013-09-13T23:06:07Z

As this has been reopened, can the title and description be modified? Dinnerbone has confirmed that the game is not supposed to delete chunks even if unrecognized items are encountered.

I propose generalizing this ticket, as MC-3973 already covers the fact that Silk Touch and lit redstone lamps don't quite mix well.

Title:

Game crashes and deletes chunks when encountering invalid items, such as lit Redstone Lamps broken with Silk Touch

Description:

When the game encounters an unrecognized or "invalid" item ID, it reacts by crashing and often deleting the chunk which contained the item. Invalid item IDs can be created in a number of ways, including breaking lit redstone lamps with a Silk Touch enchantment, or loading a world from a version where these IDs are considered valid.
Steps to Reproduce:
1. Place a redstone lamp, and power it.
2. In survival, break the lamp with a Silk Touch tool.
3. Observe that the game crashes, and when you reload the world, the chunk will be regenerated (all player-made structures removed, and all mined ores respawned).
Alternate Steps to Reproduce:
1. Load up a world in Minecraft 1.6.2.
2. Type "/give @p 75" (you must have Cheats enabled)
3. Observe that you are given an unlit redstone torch. It seems to work perfectly fine as an item when held, placed in a chest, mounted in an item frame, or placed as a block. No crashes occur.
4. Place the torch in a chest, and save/exit the world.
5. Load the world in 13w37a.
6. Observe that the entire chunk containing the chest has been refreshed.

I would have posted this as its own ticket, but now that this is reopened, that would be completely redundant. So, I would appreciate if OP or a moderator can update the title and description. Thanks in advance if anyone does!

Fenhl (Max Dominik Weber) 2013-09-20T15:50:52Z

This affects 13w38c, and is especially annoying with all the invalid blocks generated by bug in 13w38b (such as MC-31883).

pokechu22 2013-09-21T18:34:50Z

Utoh, does that mean that my 34 (piston head) in item frames for decoration will destroy the world?
Great...

Alfredo Santoyo 2013-09-26T16:16:05Z

This seems to be fixed in 13w39a. A powered redstone lamp will drop an unpowered redstone lamp using a silk touch pick and no crash occurs.

WolfieMario 2013-09-26T16:48:14Z

Definitely not fixed. Confirmed for 13w39a using the second method: loading a 1.6.4 world with unlit redstone torch items in the snapshot will cause world corruption and chunk loss.

No crash, but the following occurs, and the entire chunk is deleted:

Client> 12:44:42.003 [Server thread] ERROR km - Couldn't load chunk
Client> s: Loading entity NBT
Client> 	at oh.f(SourceFile:1072) ~[13w39a.jar:?]
Client> 	at on.a(SourceFile:155) ~[13w39a.jar:?]
Client> 	at amh.a(SourceFile:289) ~[13w39a.jar:?]
Client> 	at amh.a(SourceFile:78) ~[13w39a.jar:?]
Client> 	at amh.a(SourceFile:66) ~[13w39a.jar:?]
Client> 	at km.f(SourceFile:119) [13w39a.jar:?]
Client> 	at km.c(SourceFile:72) [13w39a.jar:?]
Client> 	at net.minecraft.server.MinecraftServer.g(SourceFile:231) [13w39a.jar:?]
Client> 	at bos.a(SourceFile:87) [13w39a.jar:?]
Client> 	at bos.e(SourceFile:103) [13w39a.jar:?]
Client> 	at net.minecraft.server.MinecraftServer.run(SourceFile:321) [13w39a.jar:?]
Client> 	at jc.run(SourceFile:582) [13w39a.jar:?]
Client> Caused by: java.lang.NullPointerException
Client> 	at pi.b(SourceFile:134) ~[13w39a.jar:?]
Client> 	at ox.a(SourceFile:112) ~[13w39a.jar:?]
Client> 	at ox.a(SourceFile:138) ~[13w39a.jar:?]
Client> 	at oh.f(SourceFile:1065) ~[13w39a.jar:?]
Client> 	... 11 more

Ben W 2013-10-14T06:23:14Z

Still affects 13w41b. Tried to /give myself block 36 for no reason, on the second attempt minecraft crashed. When I reloaded the world the chunk I was in was completely reset, all changes to it were lost.

My world's fine now, with some tricky NBT editing I managed to restore the chunk in question from a world backup.

I commented on MC-32880 with this story also, found that one first.

WolfieMario 2013-10-23T01:43:56Z

Confirmed for 1.7 prerelease.

This is really bad. I just made a world in 1.6.4 and mined lit RSlamps with silk touch in survival. I placed them inside item frames, and dropped some on the ground too.

Upon loading the world in 1.7, the entire chunks were deleted and regenerated with new terrain.

This bug is completely abusable by survival players, and poses a threat to survival servers planning to update from 1.6.4 (or earlier) to 1.7 without a world reset. If it isn't going to be fixed before 1.7 is publicly released, this ticket ought to be marked as a security issue.

You cannot expect server owners to manually check every item frame in their world to ensure that it doesn't contain a lit redstone lamp before they upgrade, and it's not trivial to tell whether a griefer has abused this bug to create new chunks in some remote part of a large server. Even if you make a backup before updating your server, this bug is just too abusable.

WolfieMario 2013-10-23T14:35:17Z

Thanks for fixing, Dinnerbone!

New behavior is to delete any invalid items encountered in item frames. However, it will also delete item data associated with a dropped item entity. This results in a dropped item which visually looks like stone, and until the item is picked up (becoming an actual stone block), the game is incredibly slow and the console spams the following rapidly and continuously:

Client> [10:31:27] [Client thread/ERROR]: Item entity 373 has no item?!
Client> [10:31:27] [Server thread/ERROR]: Item entity 373 has no item?!

Ah well, the chunks aren't getting deleted, so this is no longer nearly so abusable. I suppose even if a griefer plants these items to lag a server, they should still despawn after five minutes (I've yet to test if they can despawn) and won't have any effect until their chunks are loaded anyhow.

pokechu22 2013-10-23T20:27:10Z

Thanks for fixing, Dinnerbone!
New behavior is to delete any invalid items encountered in item frames. However, it will also delete item data associated with a dropped item entity. This results in a dropped item which visually looks like stone, and until the item is picked up (becoming an actual stone block), the game is incredibly slow and the console spams the following rapidly and continuously:

Client> [10:31:27] [Client thread/ERROR]: Item entity 373 has no item?!
Client> [10:31:27] [Server thread/ERROR]: Item entity 373 has no item?!

Ah well, the chunks aren't getting deleted, so this is no longer nearly so abusable. I suppose even if a griefer plants these items to lag a server, they should still despawn after five minutes (I've yet to test if they can despawn) and won't have any effect until their chunks are loaded anyhow.

Looks like he opted to change the block id to 0 (air). This creates the same issue, as air is a invalid id, but it proves it isn't deleting chunks.

I would advise changing it to something thoroughly worthless, such as stone (1).
Oh, and this is just my opinion, but I like using numeric ids. For instance, if you want to set a block to "Block 36" (Which is the common name for minecraft:piston_extention), I find it easier to type /setblock ~ ~ ~ 36 than /setblock ~ ~ ~ minecraft:piston_extention. What makes that annoying is you need to type all of minecraft: to use tab complete, so it is a pain to save time with that. (IE, if you type pi and then tab, you get nothing, but if you type minecraft:pi, you get piston and several other things). Most of that stuff is just me rambling, but I feel it is worth saying.

Anthony Martin 2014-08-09T20:42:27Z

I just got Couldn't Load Chunks in 14w32d:

[13:38:18] [Server thread/ERROR]: Couldn't load chunk
u: Loading entity NBT
  at wt.f(SourceFile:1244) ~[minecraft_server.jar:?]
  at wz.a(SourceFile:173) ~[minecraft_server.jar:?]
  at bfr.a(SourceFile:330) ~[minecraft_server.jar:?]
  at bfr.a(SourceFile:95) ~[minecraft_server.jar:?]
  at bfr.a(SourceFile:83) ~[minecraft_server.jar:?]
  at qq.e(SourceFile:129) ~[minecraft_server.jar:?]
  at qq.c(SourceFile:81) ~[minecraft_server.jar:?]
  at qq.d(SourceFile:116) ~[minecraft_server.jar:?]
  at aqn.a(SourceFile:276) ~[minecraft_server.jar:?]
  at aqn.f(SourceFile:272) ~[minecraft_server.jar:?]
  at aqn.p(SourceFile:659) ~[minecraft_server.jar:?]
  at aqn.a(SourceFile:2358) ~[minecraft_server.jar:?]
  at aqn.y(SourceFile:2389) ~[minecraft_server.jar:?]
  at aqn.c(SourceFile:2405) ~[minecraft_server.jar:?]
  at aus.f(SourceFile:146) ~[minecraft_server.jar:?]
  at aui.f(SourceFile:116) ~[minecraft_server.jar:?]
  at aui.j(SourceFile:90) ~[minecraft_server.jar:?]
  at aui.g(SourceFile:177) ~[minecraft_server.jar:?]
  at aus.a(SourceFile:103) ~[minecraft_server.jar:?]
  at aqn.e(SourceFile:2837) ~[minecraft_server.jar:?]
  at add.a(SourceFile:137) ~[minecraft_server.jar:?]
  at add.a(SourceFile:167) ~[minecraft_server.jar:?]
  at wt.f(SourceFile:1235) ~[minecraft_server.jar:?]
  at wz.a(SourceFile:173) ~[minecraft_server.jar:?]
  at bfr.a(SourceFile:330) ~[minecraft_server.jar:?]
  at bfr.a(SourceFile:95) ~[minecraft_server.jar:?]
  at bfr.a(SourceFile:83) ~[minecraft_server.jar:?]
  at qq.e(SourceFile:129) ~[minecraft_server.jar:?]
  at qq.c(SourceFile:81) ~[minecraft_server.jar:?]
  at qq.d(SourceFile:116) ~[minecraft_server.jar:?]
  at aqn.a(SourceFile:276) ~[minecraft_server.jar:?]
  at aqn.f(SourceFile:272) ~[minecraft_server.jar:?]
  at aqn.p(SourceFile:659) ~[minecraft_server.jar:?]
  at aqn.a(SourceFile:2358) ~[minecraft_server.jar:?]
  at aqn.y(SourceFile:2389) ~[minecraft_server.jar:?]
  at aqn.c(SourceFile:2405) ~[minecraft_server.jar:?]
  at aus.f(SourceFile:146) ~[minecraft_server.jar:?]