Occasional crash when changing blocks with a special renderer that uses states

Please attach the crash report ([minecraft|http://hopper.minecraft.net/help/guides/finding-minecraft-data-folder/]/crash-reports/crash-<DATE>-client.txt), otherwise we can not diagnose this issue.
For technical support please use the Mojang Support Center.

-- I am a bot. This action was performed automagically!

Describe what happens when you respawn, do you have any mods on? What is your enviroment? (operating system, ram, graphic card, java version etc...)

I'm having a lot of difficulty pinning down the reason for the crash - I was hoping the crash report would bring something to light. When I look in certain directions or stand in certain spots (I can't really ascertain which directions and which spots) I crash when clicking the respawn button.

Yeah, the crashes all involve the game trying to render a chest block entity, but the block there actually being air (causing issues when the game tries to get the chest's direction).

Per the crash reports, it's a different chest each time. All of the chests are also relatively close to spawn, and since they're being rendered, that makes me assume you also are close to spawn?

Perhaps this can be reproduced by just having a bunch of chests near spawn, dying, and then respawning.

I can't reproduce this buy in a new world...
Any idea what may cause this?

I do have commands that do /setblock for the chests at those positions.

Just leaving this here as it might be some useful information; @unknown experienced the same crash, with the following info:

I have this "floor is lava" command (/execute as @a at @s if block ~ ~-.01 ~ minecraft:orange_wool run kill @s) set up in 17w50a that uses /kill and when I try to respawn it crashes.

Edit: I wasn't able to reproduce the crash with the setup @unknown provided, but instead it flooded the log/console with several thousand of the following entries:

18:24:48	net.minecraft.server.MinecraftServer	Server thread	info	[miwob: Killed miwob]
18:24:48	bog	Client thread	info	[CHAT] [miwob: Killed miwob]

So I just had this happen to me a few hours ago or so, and have been testing it ever since then (well, I messed around with some other things/took a break for several hours just now technically XD). I couldn't figure out how to get it to always crash on respawn, but I figured out how to crash 100% of the time via /fill commands (leads to the same crashes as all of the ones linked here, well, except for that weird 2nd 29kb one there, which looks like some other unrelated crash). Also, I believe it happens only with block entities (just tried replacing a bunch of levers/trapdoors, nothing happened) that have a "facing" state.

Firstly, do something like:

/fill ~-32 ~-.5 ~-32 ~32 ~-.5 ~32 chest

And then repeat that command from the same spot, but replace "chest" with absolutely anything else (even air). The game should crash. Here's my own crash report from one of my last experiments:

Had a little fun with that one by starting from the world limit (wanted to see what a big flood would look like, so I used water for the fill), but it's the same deal as these crashes. I think I might have found a way to at least somewhat reliably cause the crash on respawns too (it doesn't seem to happen with teleports, though I didn't test that as extensively), which is to basically just do the same command (but bigger and without re-filling) from spawn... here's how I got it to happen a few times myself on my final tests (careful though, I just did this one more time right before I was about to post this; started the game back up to try something else, but now I just keep getting a "Ticking memory connection" crash whenever I try to open that world, but thankfully it's just a crash test world - posted the crash report for this at the end of this comment):

/fill ~-70 ~-.5 ~-70 ~70 ~-.5 ~70 sign

And then just keep killing yourself until it happens. Seemed to happen quick enough for me. Here's a report (respawn version) from my final bit of testing:

The respawn version of the reports will always report the problem block as being air, even though it's not air (and the /fill version will always state whatever you used to replace them with). When I had this happen to me the very first time by accident, I checked the location of the coordinates, and there was definitely a sign there, not air. Yet for some reason it tries to set the facing direction of "air" (or whatever you filled with in /fill crashes) instead of what's actually there.

I think that about covers it... here are some extra notes:

• /fill won't crash if you replace the blocks with themselves (which can only be done by adding the "destroy" parameter to the end of the command).

  • You'll probably get especially low fps if you try this 😛

• When crashing with /fill, the problem coordinates will always only point at a block that was within render distance (certain block entities like chests and signs unrender after getting far enough, even if you can still see other blocks in that area).

• The positions mentioned in the crashes seem to favor the corners of chunks (F3+G to see borders), usually one of the (but not limited to) blocks in the 4x4 section of corners (mostly the north-west ones, and typically favors the north edge). Often picks one in the very corners from what I remember.

• Replacing at least a 21x21 or so area of (non-facing ones only I think) block entities (e.g. changing enchanting tables into mob spawners) with different block entities will cause visual bugs based on what was first in that spot (in the enchanting table -> mob spawners example, you'll get floating books in cages but no mob spawner effects). You can even safely replace non-facing block entities with facing ones, but they'll be invisible (but still interactable). Seems like as long as they don't render at all, it also won't crash at all (meaning you can probably safely switch block entities around all you want when in that state regardless of what block entity you use). Destroying the blocks by hand while they're visually bugged will fix that spot (until you do the process over again for it), as will re-logging or reloading the chunks via travel.

  • Similarly, replacing signs with any kind of chest with my /fill suggestion doesn't seem to crash the game, but the other way around will (unless they're completely invisible due to the above glitch). The chests also all look like they turn into wall signs, but can still be opened.

  • If you do this with chests or trapped chests, then convert them into ender chests and open one, you get a "Ticking block entity" crash instead of a "Rendering Block Entity" one. But the cause of the crash is still related to the "facing" aspect. Evidence:

Well, this all took longer than I thought it would to test/write XD Also interesting to know that linking attachments in a comment makes them show up in Activity at the time of attaching, rather than at post, haha. Noticed it when I checked this page in another tab a handful of hours ago to see if anyone had posted in the time I was writing. Whew... looking at the timestamp of my original crash (didn't link it here), it was precisely 15 hours ago... I think it's break time XD

P.S. Here's the possibly-permanent "Ticking memory connection" crash I get whenever I try to open that world now:

Hm, interesting. I'm not completely well-versed in the rendering system, but I will note a few things:

• The 29 kb crash references bnv; that's the font renderer. There is some recursive method in there that's used to fit strings, but it doesn't exactly make sense.

• The "Ticking memory connection" crash is in statistics-related code; you probably corrupted the stats folder (so unrelated to this issue).

Regarding this:

Also, I believe it happens only with block entities (just tried replacing a bunch of levers/trapdoors, nothing happened) that have a "facing" state.

I'd guess it's actually a bit more general - any block entity that uses a block state during its rendering process (which would generally be facing, but might also affect daylight sensors with their (new) inverted state). I know that block entities have some kind of weird special rendering process, though I don't know the details of it.

(also, I edited your comment to fix the strikethrough in the commands, hope you don't mind 🙂 EDIT I see you actually edited yourself before I edited it, whoops)

Yeah I haven't posted very much here yet, messed up the command bits with a bunch of accidental strikethroughs at first XD I'll probably get used to the formatting eventually!

On that note, time to see if I use quoting properly (edit: darn, failed the first time!):

I'd guess it's actually a bit more general - any block entity that uses a block state during its rendering process (which would generally be facing, but might also affect daylight sensors with their (new) inverted state).

Seems like it... Also, I just tried my commands with daylight sensors, but nothing acted up. I'd try with inverted ones too, but it's a pain to click them all (tried it with a few hundred before giving up though at least) since I don't know what in the world the nbt names for the different block states are now (and running /data get on the ones you can use that command on doesn't show them either). I did just try it with piston heads as well, but those didn't trigger it either, despite being a block entity and having a facing value (by the way I've just been summoning 1 row at a time for the wall-required types of blocks, like the levers and piston heads, since other than the first row, they break without a supporting back wall (or break immediately if the "back" gets updated at all, like with piston heads)). I just tried it with beds, and it crashed, with the error saying that the block I replaced them with was missing a bed part:

So yeah... seems like any block entities that render/unrender like normal entities where distance is concerned, in addition to having different models based on blockstate values like you said, the crashes can/will happen.

P.S. Is there any way to actually find out the new blockstate nbt names? Along with being very handy in general, it'd help to know what they are for something like filling in a bunch of space with inverted daylight sensors to test for crashes (though I think the daylight sensors are safe either way since they don't have the distance-based rendering/unrendering qualities of normal entities). Only new one I've managed to find out is the one for custom blocks in minecarts ( DisplayState:{Name:""} quotation marks optional, just input a block id like diamond_block in Name, along with the usual CustomDisplayTile:1), which I did by summoning one in 1.12 just a bit ago and then /data get-ing it in the snapshot.

Edit: Not sure what's going on with the weird extra lines for that DisplayState bit at the end, tried without the spaces just now but that didn't fix it

though I think the daylight sensors are safe either way since they don't have the distance-based rendering/unrendering qualities of normal entities

That's a good point, and something I forgot about. Daylight detectors don't have any special kind of special renderer; they just use block states with models. Only the block entities with a special renderer and not a regular model would have this issue... which would include beds as you described.

I don't think it being inverted/not inverted would make a difference – the issue seems to be when it's trying to get the value of a state, not when it's using the value itself.

Is there any way to actually find out the new blockstate nbt names?

Look at the block with F3 enabled; all of the states are listed on the right side. It's actually quite convenient. There's also the flattening page. Do note that states technically aren't NBT; there's a fixed set of values (but I'm not sure exactly how to explain what they are).

Not sure what's going on with the weird extra lines for that DisplayState bit at the end, tried without the spaces just now but that didn't fix it

"{" and "}" do weird things, which seems to include randomly adding newlines (I'm not exactly sure why). You can escape them with a backslash, but it's just odd behavior that I don't fully understand either. This escaping is needed even when in inline code formatting ({{text}}) but not in {noformat}. There is a preview button, which can be useful for checking formatting (but if it's something that seems like it should be correct, it's generally not needed)

There is a preview button, which can be useful for checking formatting (but if it's something that seems like it should be correct, it's generally not needed)

Ahh, so that's what that little blue icon does, I think I only tried clicking it once before and saw nothing, so I thought it was just a minimize button, haha. Nothing shows up when mousing over it either. Thanks for the backslash tip too (probably overlooked it due to being right near the end of the formatting help & next to the emoticons)!

Look at the block with F3 enabled; all of the states are listed on the right side. It's actually quite convenient. There's also the flattening page. Do note that states technically aren't NBT; there's a fixed set of values (but I'm not sure exactly how to explain what they are).

I knew about F3's block info, as well as that page's existence, but I didn't know I had to use square brackets for states! That's the one thing that was stumping me for a while now, so thank you for getting me to take a closer look at the page (found it after following the command note #2 link there, which lead to the main 1.13 page, and eventually the Blocks section) 😃 Also handy to know that I could have found the DisplayState nbt info there too, I'll definitely be referring to it in the future for the rest of the new nbt names (and as far as states go, apparently they have auto-complete suggestions while writing them, so handling those will be a piece of cake 😃)! And yeah I think I understand what you mean about states being separate; they were always their own numeric value separate from the nbt section of commands after all.

I should probably try to come up with something relavent to say about the bug instead of just saying thanks, so uhh... *tests things*

Doesn't happen with inverted daylight sensors after all (figured I should make sure)... And apparently, working near many piston heads causes lag spikes, especially the short piston heads. It's probably a bug that deserves its own thread, but suffice it to say, there's some kind of ((un)even?) square radius (about 36 (or maybe 32?) long by 19ish (16?) high? Dunno about width) around piston heads that will cause you to lag spike whenever there are block updates (and I think especially de-lighting updates?) within it (the more piston heads, the laggier). I think chunks may have a role in the dimensions.

Anyway I'll stop here before I go too far off on a tangent, thanks again for pointing the way to the info I'd been needing!

Replacing at least a 21x21 or so area of (non-facing ones only I think) block entities (e.g. changing enchanting tables into mob spawners) with different block entities will cause visual bugs based on what was first in that spot

There's actually already a report for this: MC-82703, just so you know.

Also, piston heads actually don't have a block entity - only the "in motion" piston block thing does (which is sometimes refered to as "block 36", but officially is minecraft:moving_piston). Unfortunately testing with that is currently not possible due to MC-123304.

This also happens when you load a bunch of chests with a structure block.

Originally posted in MC-110399 (related or same issue?) but, I was able to get this crash with furnaces in a structure file:

"Caused by: java.lang.IllegalArgumentException: Cannot get property bcw{name=rotation, clazz=class java.lang.Integer, values=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]}
as it does not exist in bci{block=minecraft:furnace, properties=[facing, lit]}"

Bug extant in 18w05a. Crash report attached:

Also important to note that structure blocks can trigger this issue like the fill command.

Affects 18w07c

Reposting explanation and fix from https://github.com/MinecraftForge/MinecraftForge/pull/4811

When rendering tile entities, RenderGlobal.renderEntities loops over the list given by CompiledChunk.getTileEntities for each chunk section, and calls TileEntityRendererDispatcher.render on each one.

The list of tile entities with custom renderers is populated from RenderChunk.rebuildChunk, while looping over block positions and rendering regular block models.

As rebuildChunk may be running on a worker thread, it is possible for a tile entity that is added to that list to subsequently be removed from the world by the main thread.
Then, when renderEntities is called, it may try to render a tile entity that no longer exists at that position, which causes a crash if the render method attempts to access any property of the no-longer-present blockstate.

Vanilla's TESR implementations are generally unaffected in 1.12 because they tend to use TileEntity.getBlockMetadata instead of direct property value lookups. It seems that the removal of metadata in the 1.13 snapshots caused the problem to become visible there.

This is resolved here by adding a check for TileEntity.isInvalid to the renderer lookup. Tile entities that have been removed from the world will have been invalidated, so adding this check prevents attempts to render them from causing crashes.

Got same error while cloning "replace move" an area that contains hoppers by two blocks

java.lang.IllegalArgumentException: Cannot get property bph{name=facing, clazz=class en, values=[north, east, south, west]} as it does not exist in Block{minecraft:hopper}java.lang.IllegalArgumentException: Cannot get property bph{name=facing, clazz=class en, values=[north, east, south, west]} as it does not exist in Block{minecraft:hopper} at boe.c(SourceFile:95) at cyk.a(SourceFile:71) at cyi.a(SourceFile:148) at cyi.a(SourceFile:128) at cwh.a(SourceFile:694) at cwb.b(SourceFile:984) at cwb.a(SourceFile:893) at cwb.a(SourceFile:753) at ciq.c(SourceFile:814) at ciq.a(SourceFile:379) at net.minecraft.client.main.Main.main(SourceFile:144)

Client crashes, server is ok - reports player logged out.

Opening the world in the file bug-world.zip that I attached and loading the structure blocks in the order displayed on the signs causes this bug. My crash file: crash-2018-06-11_18.58.57-client.txt

This is still a problem in 1.13 pre 2

This is especially an issue to me cause I use a datapack and it uses player heads as different ores and crashes me all the time when the heads are generated in water 

Seems to be fixed in 1.13-pre 3.

I still have this problem in 1.13 pre 3

Sorry, I mixed up with another crash.

still and issue in 1.13 pre 3 I really want this fixed its such an annoying bug and really limits the game with player head chests and playerheads

still a issue in 1.13 pre 5

Still an issue in 1.13 full release. Crashlog attatched.

Confirmed for 18w30b

Confirmed for 18w31a

Can someone please provide steps to reproduce this crash? I cannot confirm with the steps in the description.

Confirmed for 18w32a

Can someone please provide steps to reproduce this crash? I cannot confirm with the steps in the description.

 Use the /fill command to place a big box of chests then use /fill again to replace the chests with grass blocks.

How do your commands differ from the ones in the ticket (if at all)? Do you change the y value?

Here are the commands I use:

/fill -289 84 50 -268 107 0 chest replace
/fill -289 84 50 -268 107 0 grass_block replace

{{}}

Can confirm with the provided commands.

Description: Rendering Block Entity

java.lang.IllegalArgumentException: Cannot get property bmb{name=facing, clazz=class ep, values=[north, south, west, east]} as it does not exist in Block{minecraft:grass_block}
	at bkx.c(SourceFile:95)
	at cvz.a(SourceFile:71)
	at cvx.a(SourceFile:148)
	at cvx.a(SourceFile:128)
	at cub.a(SourceFile:693)
	at ctv.b(SourceFile:967)
	at ctv.a(SourceFile:876)
	at ctv.a(SourceFile:750)
	at cfq.c(SourceFile:850)
	at cfq.a(SourceFile:395)
	at net.minecraft.client.main.Main.main(SourceFile:144)

However, this crash is MC-135453. AFAIK this issue has been fixed.

Sorry to revive this, but what exactly is the difference between MC-135453 and MC-123363?

Different crash.

Assuming the relevant code hasn't changed since 1.13, this does not appear to have been fixed correctly.

Crashes can still occur in the cases where the affected blocks are replaced with anything that isn't air.

The check for air should be replaced with a check of the appropriate flag, as per the original recommendation.

This is still not fixed correctly in 1.13.2.

The 1.13.2 code for TileEntityRendererDispatcher.render (in MCP names):

if (!hasNoBlock && (!tileEntityIn.hasWorld() || !tileEntityIn.getBlockState().getBlock().hasTileEntity())) {
   return;
}
tileentityrenderer.render(tileEntityIn, x, y, z, partialTicks, destroyStage);

In this case the previous check for tileEntityIn.getBlockState().isAir() has been replaced with a check for tileEntityIn.getBlockState().getBlock().hasTileEntity(), but this is still not fully correct.

In the case of two blocks: A (with associated block entity X), and B (with associated block entity Y), where A and B do not have the same state properties, then rapidly switching A <-> B will still crash.

One of the principle underlying causes of the issue here is blocks being replaced with a different block. The key property of the new block here is simply that it is not the old block and therefore can have an entirely different set of state properties and behaviours. It is not appropriate for an entity associated with the first block to operate on the second, which is why, when such a block change occurs, the old block entity is removed.

The issue here is that the render code still has a reference to that old entity and attempts to render it.

The proper solution for that issue is simply to ensure that the intended removal of the old block entity is correctly detected, which is probably best comunicated directly through the block entity itself.

The remaining part of the issue is the matter of crashes upon respawning, which are caused due to attempting to render block entities from unloaded chunks. Either unloaded chunks need to be checked for here, or, preferably, block entities in unloading chunks should be properly marked as pending removal.

See https://github.com/MinecraftForge/MinecraftForge/pull/5512 for further explanation.