All blockstate crashes go here (cannot get property...)
williewillus opened this issue · 63 comments
Cannot get property <...> as it doesn't exist on <...>
So we don't have multiple of the same thing
EDIT May 2020:
VoxelMap seems to be a common denominator across all of these issues. It appears to be unsafely accessing the world (possibly from off-thread). This causes the tile entity to somehow be accessed even though its host block is not in place.
Known workarounds:
- Remove VoxelMap and get another map mod (I recommend Xaero's)
- Update above 1.12, as vanilla has additional safety checks to prevent this from happening
- Place a block directly above the problematic block (usually mana pools) so VoxelMap reads that block for the map and doesn't touch the pool
Permanently resolved the conflict with VoxelMap thanks to @ACGaming's https://github.com/ACGaming/VoxelMapFixes/releases.
Sponge appears to be a common theme throughout these...does it make TE's tick before their host blocks are actually there?
Tagging myself to find this easier later.
Sponge appears to be a common theme throughout these...does it make TE's tick before their host blocks are actually there?
That wouldn't even be surprising tbh...
We'll test some more after updating to latest sponge & forge, to see if it still happens (I think I've seen in the changelogs something that could be related, can't find it back though).
Well #2181 doesn't involve Sponge, AFAIK
@Aaron1011 thoughts?
Yes. Blocks and TileEntities arrive in different packets, so it is important that a custom Block renderer be prepared for its TileEntity to not be present, and vice versa.
this is not the renderer, this is a tile entity ticking before its block data is even in place (or after its block data is gone), which makes no sense at all.
in addition, under the standard vanilla (and forge) protocol, te's arrive in the same packet as blocks, right after the block data. not sure if sponge messes with that or not.
Oh ho, you're right. It was changed since the last time I checked. The forge guys helpfully inserted this comment:
//TODO: FDix Mojang's fuckup to modded by combining all TE data into the chunk data packet... seriously... packet size explosion!
on a slightly unrelated note, that seems pretty much fine now with the getUpdateTag/getUpdatePacket split :P
so this is a forge issue? i just had a server crash
http://pastebin.com/RvjynMrd
I have no idea what it is, but there seems to be sponge pattern common in all of these.
For the sake of contributing, I'm getting this crash on client side, but not server side.
https://paste.ee/r/hHpMl
That wouldn't even be surprising tbh...
We'll test some more after updating to latest sponge & forge, to see if it still happens (I think I've seen in the changelogs something that could be related, can't find it back though).
So yeah we updated sponge & forge to latest, and still getting this.
I guess on player join sponge might be sending the TE before the actual block, but not on regular world loading which'd explain why people logging in away and then loading the zone don't crash.
(the above crash report happens right on server join btw)
To reproduce, might need a server restart in-between. Even then, the client doesn't crash every time.
@Tencao but was it a sponge server?
@williewillus yes.
My previous comment applied to that crash report too btw, I'm helping him out with his (currently in beta) server ^-^
@williewillus Yes it was, but recently I've not experienced this type of crash on the server side of things, only the client, so @Bluexin 's theory on TE's before the actual block may be true.
I'm getting a blockstate crash related to the redstring interface
https://paste.ee/p/tjejg
Could it have something to do with it being pointed at a Chisels & Bits block?
Running this on a regular server (not sponge)
Version Information
Forge version: 12.18.3.2422
FML Version: 8.0.99.99
Botania version: r1.9-341
Further Information
Link to crash log: https://paste.ee/p/BtG8X
Steps to reproduce:
- I really don't know... sometimes it happens on joining the server, sometimes after playing a bit
What I expected to happen:
Not to crash
What happened instead:
Crashed while joining or playing on the server (FTB Beyond).
Cause (at least what I think it is):
It is trying to get information about a manapool from an air block wich results in a (client only) crash.
There are no exceptions on the server side.
Name: botania:pool // vazkii.botania.common.block.tile.mana.TilePool
Block type: ID #0 (tile.air // net.minecraft.block.BlockAir)
Block data value: 0 / 0x0 / 0b0000
Block location: World: (15,68,191), Chunk: (at 15,4,15 in 0,11; contains blocks 0,0,176 to 15,255,191), Region: (0,0; contains chunks 0,0 to 31,31, blocks 0,0,0 to 511,255,511)
Actual block type: ID #0 (tile.air // net.minecraft.block.BlockAir)
Actual block data value: 0 / 0x0 / 0b0000
Thats interesting and important I think. If I just said something wrong feel free to ignore me, I only have a bit of experience with coding MC mods.
Modpack Info
Running FTB Beyond 1.11.0 (Game Version 1.10.2). I know that Beyond has its own issue tracker but as far as I can tell this is directly related to Botania.
Note
I'm submitting this for a friend so I might not be always able to reproduce or reply instantly.
people still affected by this issue: does it happen in forge >= 2671? there's a fix in that build that should help.
Yes,I have this crash
Forge:Forge 14.23.1.2554
Botania+r1.10-354.jar
Time: 5/9/18 11:34 PM
Description: Ticking block entity
java.lang.IllegalArgumentException: Cannot get property PropertyEnum{name=variant, clazz=class vazkii.botania.api.state.enums.PoolVariant, values=[DEFAULT, CREATIVE, DILUTED, FABULOUS]} as it does not exist in BlockStateContainer{block=minecraft:air, properties=[]}
at net.minecraft.block.state.BlockStateContainer$StateImplementation.func_177229_b(BlockStateContainer.java:209)
at vazkii.botania.common.block.tile.mana.TilePool.func_73660_a(TilePool.java:252)
at net.minecraft.world.World.func_72939_s(World.java:1832)
at net.minecraft.client.Minecraft.func_71407_l(Minecraft.java:1845)
at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:1096)
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:397)
at net.minecraft.client.main.Main.main(SourceFile:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:196)
at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:231)
at org.multimc.EntryPoint.listen(EntryPoint.java:143)
at org.multimc.EntryPoint.main(EntryPoint.java:34)
A detailed walkthrough of the error, its code path and all known details is as follows:
-- Head --
Thread: Client thread
Stacktrace:
at net.minecraft.block.state.BlockStateContainer$StateImplementation.func_177229_b(BlockStateContainer.java:209)
at vazkii.botania.common.block.tile.mana.TilePool.func_73660_a(TilePool.java:252)
-- Block entity being ticked --
Details:
Name: botania:pool // vazkii.botania.common.block.tile.mana.TilePool
Block type: ID #0 (tile.air // net.minecraft.block.BlockAir)
Block data value: 0 / 0x0 / 0b0000
Block location: World: (-145,70,719), Chunk: (at 15,4,15 in -10,44; contains blocks -160,0,704 to -145,255,719), Region: (-1,1; contains chunks -32,32 to -1,63, blocks -512,0,512 to -1,255,1023)
Actual block type: ID #0 (tile.air // net.minecraft.block.BlockAir)
Actual block data value: 0 / 0x0 / 0b0000
Stacktrace:
at net.minecraft.world.World.func_72939_s(World.java:1832)
Since I have just had this crash occur to me on both a Direwolf20 server and now in a SF3 server. I'll just leave my own crash report here as well.
https://pastebin.com/9Ra8RmUy
The player who owns the island this occurred in, they informed me this may have something to do with the crash they caused. Not long ago the player right clicked a manapool with a mana ring and the server crashed. I was mid transit to them via a /tpa command which was being handled by Sponge. Right as soon as I arrived they crashed the server.
Just to add a datapoint, I'm getting this as a client-side crash (not server-side) with vanilla Forge, not sponge. This looks very much like the server sent a tile entity to the client without sending the associated block as well. Another player on the same server that is in the general area of the tile entity in question is unaffected.
Additional data: making the view distance smaller allowed the crashing player to rejoin the server, but the client would crash again upon moving closer to the problematic block. Setting view-distance low enough (4) allowed the affected player to move close enough that, after the crash for "getting too close", setting the server view-distance it back to the default of 10 allowed the player to join successfully.
Ok, here's what's happening on our private server:
Sometimes, but not consistently, on returning to an area in which mana pools have been placed, a player's client will crash with a "cannot get property PropertyEnum" because the block is actually "minecraft:air". The location at which the incorrect block is located is always an air block, with x and z coordinates that always have the low four bits equal to 15 (that is, they're always in the +,+ corner of a chunk). The y coordinate is always the lowest air block in the clear column above whatever's there already.
Actually placing a mana pool in that location allows that player to enter the affected area, although sometimes it is necessary to add two or three "phantom" pools (at different locations) before the problem abates.
In addition, adding a pool once is no guarantee that a second pool will not be required later. I have a couple places already where there are pools stacked on top of pools to deal with this issue. Some of these pools are in locations where there has never been a pool in this world.
My best guess is that the mana pool tile entities are being relocated from elsewhere in the chunk (or region) as they're transferred to the client, probably by the tile entity itself being corrupted during data transfer. The fact that they're always at in-chunk coordinates of 15,15 is highly suspicious to me.
I've been getting this crash on my server as well, client side only as usual. Adding some extra debugging to Botania showed that, in our case at least, it turned out to be VoxelMap somehow causing extra tile entities to be created alongside the correct ones, these extra tile entites pointed at some random air block and subsequently crashed. Removing VoxelMap resolved these crashes for us.
Sponge is not running on our server.
Further update on the issue we've been having in light of @gamax92's comment: when this issue recurred, clearing VoxelMap's map cache resolved the issue. Given that VoxelMap on 1.12.1 (which is what we're using at the moment) has loads of other bugs, I'm comfortable blaming this crash on VoxelMap.
We're going to be looking for replacement mapping utilities, since VoxelMap appears not to be being actively maintained.
While it might arguably a good thing from a robustness standpoint if the mod didn't actually crash the client in this circumstance, I cannot fault Botania for not adequately coping with another mod's misbehavior creating spurious phantom tile entities.
While building out my Botania empire in Stoneblock, I set up a 7x7 internal room with all endoflames. These flowers are all connected to 1 of 4 basic spreaders. The spreaders are all pointed into a mana splitter into 1 of 4 pools. From one of the pools, I have a spreader into the runic alter. During this time, I began having crashes. It is now at the point where I can't even open the world. I believe it is down to botania that is the issue because of the line
java.lang.IllegalArgumentException: Cannot get property PropertyEnum{name=variant, clazz=class vazkii.botania.api.state.enums.PoolVariant, values=[DEFAULT, CREATIVE, DILUTED, FABULOUS]} as it does not exist in ExtendedBlockState{block=botania:specialflower, properties=[color, type]}
Version Information
Forge version: 14.23.5.2768 244
Botania version: 1.10.357
Further Information
Link to crash log: https://gist.github.com/bretterer/85329f4d99acc676b8462357ecb27164
Steps to reproduce:
Not sure the best way to re-produce it.
I have a Stoneblock map and a room 7x7 internal room with endoflame flowers being fead by coal. These feed into 4 different mana pools through a splitter.
Link to World: https://drive.google.com/open?id=1gC1R0j8LoAy2XiIZu00RSJbIruUOUgy8
What I expected to happen: Able to open the world
What happened instead: Crash on world load
Hello
I'm also experiencing this crash it seems. Both single player and open to Lan, heavily modded, but I'm not using a sponge server or anything. I do have Voxel map, but I find this thread really confusing to sort through to figure out if that is the problem. I'm not even sure if my crash belongs on this thread because it doesn't have the "does not exist" part of it that I can see..... If it is, is there a solution besides removing voxel map?
1.12.2 + forge b2805, botania 1.10-360
Here is the crash log:
https://paste.dimdev.org/agegesigaz.mccrash
It is blaming the mana pool .. ticking block entity, cannot get property.
yes, your issue belongs here. it looks like voxelmap is a common factor in these crashes, can you try without it?
I will disable voxel/lite loader and see if it happens. Maybe I can pin down how to get it to consistently happen. I noticed that it does seem to only happen either on single player or to the person connecting to the lan and not to the person hosting the lan though, at least I don't remember it happening in another combination. Any ideas on why voxel map would be causing this? I'm really bummed that seems to be the culprit. I haven't found another map mod that does mob specific icons and biome display etc.
Welp.
1.12.2 forge .2811 + liteloader [botania 1.10-360]
Mana pool crashed my game, and the logs have a striking resemblance to what you guys are talking about.
LOG:
The game crashed whilst ticking block entity
Error: java.lang.IllegalArgumentException: Cannot get property PropertyEnum{name=variant, clazz=class vazkii.botania.api.state.enums.PoolVariant, values=[DEFAULT, CREATIVE, DILUTED, FABULOUS]} as it does not exist in BlockStateContainer{block=minecraft:air, properties=[]}
I have voxelmap rn, and im gonna remove it to see what happens.
So, should I stop using mana pool entirely?
-- Block entity being ticked --
Name: botania:pool // vazkii.botania.common.block.tile.mana.TilePool
Block type: ID #0 (tile.air // net.minecraft.block.BlockAir // minecraft:air)
Block data value: 0 / 0x0 / 0b0000
Block location: World: (981,65,-4093), Chunk: (at 5,4,3 in 61,-256; contains blocks 976,0,-4096 to 991,255,-4081), Region: (1,-8; contains chunks 32,-256 to 63,-225, blocks 512,0,-4096 to 1023,255,-3585)
Actual block type: ID #0 (tile.air // net.minecraft.block.BlockAir // minecraft:air)
Actual block data value: 5 / 0x5 / 0b0101
Block Entity NBT: {manaCap:-1,color:0,canSpare:1b,outputting:0b,outputKey:"",mana:0,x:990,y:63,z:-4088,id:"botania:pool",canAccept:1b,fragile:0b,inputKey:""}
Block Entity NBT : {x:990,y:63,z:-4088}
Block location: World: (981,65,-4093)
Seems here's a TileEntity position mismatch, but why?
It seems some people are pointing to voxelmap as thr cause of their crash. I don't use voxelmap but journeymap.
Yet another one that has similar cause: https://paste.ubuntu.com/p/F6vNkrf89Y/
This one is rather interesting - it's singleplayer, using Forge 14.23.4.2705... anyone interested in investigating it?
@3TUSK That's another VoxelMap-induced crash. Remove/disable VoxelMap.
net.minecraft.util.ReportedException: Ticking block entity at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:773) ~[MinecraftServer.class:?] at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:668) ~[MinecraftServer.class:?] at net.minecraft.server.integrated.IntegratedServer.func_71217_p(IntegratedServer.java:185) ~[chd.class:?] at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:526) [MinecraftServer.class:?] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_51] Caused by: java.lang.IllegalArgumentException: Cannot get property PropertyEnum{name=variant, clazz=class vazkii.botania.api.state.enums.PoolVariant, values=[DEFAULT, CREATIVE, DILUTED, FABULOUS]} as it does not exist in ExtendedBlockState{block=appliedenergistics2:cable_bus, properties=[]} at net.minecraft.block.state.BlockStateContainer$StateImplementation.func_177229_b(BlockStateContainer.java:201) ~[awu$a.class:?] at vazkii.botania.common.block.tile.mana.TilePool.func_73660_a(TilePool.java:252) ~[TilePool.class:?] at net.minecraft.world.World.func_72939_s(World.java:1832) ~[amu.class:?] at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:613) ~[oo.class:?] at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:767) ~[MinecraftServer.class:?] ... 4 more
Botania r1.10-356
Getting this crash while Running the Stoneblock Pack, single player. I had to rollback the previous save since it wouldn't load in. It's crashing seemingly at random now.
crash-2018-10-17_01.37.17-server.txt
Another Crash due to ticking blockstate
crash-2018-10-18_22.29.19-server.txt
This doesn't seem to always happen when VoxelMap is installed as shown here: #2960
Is there nothing Botania can do about it?
Update: The VoxelMap crashes when rendering a mana pool from Botania stop when setting Block Transparency to OFF.
Update: The VoxelMap crashes return even with Block Transparency set to OFF if there is snow on the mana pool.
Edit: it happens sometimes even if there is no snow. Tweaking VoxelMap's settings can lower the crash rate but it still happens, unfortunately.
I also had a bunch of these issues (cannot get property...) and have no idea what causes them.
everything in the same world (name changed because i wanted a backup first)
https://pastebin.com/jrSDRvnH
https://pastebin.com/BaiRTy0R
https://pastebin.com/pmNMFtkj
https://pastebin.com/3XEu5B8t
https://pastebin.com/Nn4zkZXG
https://pastebin.com/rH76nKqK
https://pastebin.com/s4s3Kpk4
And a screenshot of my setup:
https://imgur.com/a/D66PPZI
There are also 25 mana pools with sparks on top below the setup for mass storage
Also i am using the latest botania version (363)
@Megablocklobster Do you have a direct way to reproduce the crash?
as i still have no idea what caused it: no. the only thing i know is that it doesnt crash when no mana is produced. The crashes i posted resuled from simply letting it run after removing the block mentioned in the last crash report. sorry
Report. Newest .361 Botania does not crash with journeymap
Still crashes with voxelmap
What is happening?
Another one bites to dust.
https://paste.dimdev.org/ezizemaduw.mccrash
Seems to happen when VoxelMap tries to render a mana pool after leaving the chunk and coming back.
https://paste.dimdev.org/etotupaqeh.mccrash
This issue is stale because it has been open for a while with no activity. Remove stale label or comment or this will be closed soon.
@williewillus Changing Forge's config to automatically remove erroring tile entities is a workaround for this issue.
closing as 1.12 is no longer being updated, but keeping it pinned for info.
to reiterate: use a different map mod or update above 1.12
I am also receiving the same error:
https://paste.dimdev.org/diboroqoko.mccrash
We can reliably recreate the error by walking out of the chunk, then walking back into it. Once we're within 300 blocks of the manapool, the client crashes with the above error.
Troubleshooting more, we were able to stop crashes by placing a block a few spaces above the mana pool, blocking it from the sky. Now moving in and out of the chunk does not crash the game.
Additionally, my setup is stock 1.12.2 v1.1.1 - none of the configs have been modified.
that pretty much solidifies it as voxelmap (again).
It's in your mod list, and placing a block above the pool would prevent voxelmap from touching the pool (since the map only reads the top block at each location)
I've forwarded this issue to the VoxelMap author as well over https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-mods/2261180-voxelmap-1-15-2-to-1-7-10-a-minimap-and-worldmap?comment=2011
this look like Voxelmap again?