The bug
In certain cases, the game can crash when a block with a special renderer changes, with an IllegalArgumentException regarding a property that does not exist in a certain block.
For example, with chests:
java.lang.IllegalArgumentException: Cannot get property bbu{name=facing, clazz=class ef, values=[north, east, south, west]} as it does not exist in bbi{block=minecraft:air, properties=[]}[^(17w50a) crash-2017-12-21_23.12.20-client.txt]
Description: Rendering Block Entity
java.lang.IllegalArgumentException: Cannot get property bbu{name=facing, clazz=class ef, values=[north, east, south, west]} as it does not exist in bbi{block=minecraft:air, properties=[]}
at bbi$a.c(SourceFile:173)
at cce.a(SourceFile:70)
at ccc.a(SourceFile:134)
at ccc.a(SourceFile:122)
at cad.a(SourceFile:674)
at bzx.b(SourceFile:1185)
at bzx.a(SourceFile:1093)
at bzx.a(SourceFile:951)
at bne.b(SourceFile:820)
at bne.a(SourceFile:380)
at net.minecraft.client.main.Main.main(SourceFile:140)How to reproduce
Use the following commands to place and then change a large quantity of chests:
/fill ~-32 ~-.5 ~-32 ~32 ~-.5 ~32 chest
/fill ~-32 ~-.5 ~-32 ~32 ~-.5 ~32 grass_blockGeneralizations
This bug is known to affect the following block entities:
Chests (and trapped chests and ender chests)
Signs
Beds
Shulker boxes
Skulls
It does not seem to affect the following:
Daylight detectors (no special renderer)
Furnaces (no special renderer)
Structures blocks: Use special renderer in 1.12.2 but could not produce crash
moving_piston: Apparently not usingfacing?
Other notes
While /fill is used to consistently reproduce, this same issue has occurred with other cases – usually death. Death temporarily changes all blocks to air during respawning, which would cause this same underlying problem of mismatched blocks (probably). It seems possible to have this happen with fewer chests, it just gets rarer.
Linked issues
is duplicated by 10
MC-124012
Crash: 'Rendering Block Entity' java.lang.IllegalArgumentException: Cannot get property bco
Resolved
MC-124184
When working with ≥64 chests or shulker boxes and /fill in the same chunk, some funky errors occur.
Resolved
MC-124682
Crash: Rendering Block Entity "Cannot get property"
Resolved
MC-124715
Crash upon Death in Adventure Map
Resolved
MC-124746
Crash upon respawning.
Resolved
relates to 3
MC-123304
"Ticking block entity" NullPointerException Game crash 64 Pistons in 1 chunk
Resolved
MC-110399
Hopper: java.lang.IllegalArgumentException: Cannot get property atw{name=facing, clazz=class cv, values=[down, up, north, south, west, east]} as it does not exist in atk{block=minecraft:<block>, properties=[]}
Resolved
MC-135453
Crash while rendering block entity
Resolved
Attachments
Comments 38
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.
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.
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.
michael
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!