mojira.dev
MCPE-21375

Game still crashes trying to access zombie spawner collection chest

So this issue has been happening since the last few updates... The chest in the video is fed from a zombie spawner and on any attempts to move/break/open the chest the game immediately crashes. I really don't want to recreate my world as it's been years in the making.

Related issues

Attachments

Comments

migrated
[media][media]
migrated
[media][media]
migrated
[media][media]
migrated

I have a chest like that too (android), right in the middle of my archive.
Have tried everything to get rid of it as you have, move/break/open/hoppers etc, touch it and MCPE crashes instantly.
I even tried /setblock 1281 66 85 dirt replace and /fill a 9 block cube around it, instant crash.

When I load the world into MCPEViz and check the logs it can read the contents of the chest ok, the log is below but MCPE just cannot handle it at all without crashing.

I expect you'll have to live with it as I have 😞 I feel your pain!!!

overworld-ParsedTileEntity: [Pos=(1282, 66, 85 @ image 3650, 2693) Sign=[Crashes if / opened / DO NOT TOUCH / ]]
overworld-ParsedTileEntity: [
Pos=(1281, 66, 85 @ image 3649, 2693)
Chest=[
[Block:Dirt Damage=0 Count=64 Slot=1]
[Block:Dirt Damage=0 Count=64 Slot=2]
[Block:Dirt Damage=0 Count=64 Slot=3]
[Block:Dirt Damage=0 Count=64 Slot=4]
[Block:Dirt Damage=0 Count=64 Slot=5]
[Block:Dirt Damage=0 Count=64 Slot=6]
[Block:Dirt Damage=0 Count=64 Slot=7]
[Block:Dirt Damage=0 Count=64 Slot=8]
[Block:Dirt Damage=0 Count=64 Slot=9]
[Block:Dirt Damage=0 Count=64 Slot=10]
[Block:Dirt Damage=0 Count=64 Slot=11]
[Block:Dirt Damage=0 Count=64 Slot=12]
[Block:Dirt Damage=0 Count=64 Slot=13]
[Block:Dirt Damage=0 Count=64 Slot=14]
[Block:Dirt Damage=0 Count=64 Slot=15]
[Block:Dirt Damage=0 Count=63 Slot=16]
[Block:Dirt Damage=0 Count=64 Slot=17]
[Block:Dirt Damage=0 Count=64 Slot=18]
[Block:Dirt Damage=0 Count=64 Slot=19]
[Block:Glass Pane Damage=0 Count=16 Slot=20]
[Block:Grass Block Damage=0 Count=8 Slot=21]
[Block:Grass Path Damage=0 Count=1 Slot=22]
[Item:Coal Damage=0 Count=6 Slot=23]
[Block:Dirt Damage=0 Count=64 Slot=24]
[Block:Sandstone, Smooth Damage=2 Count=51 Slot=25]
[Block:Dirt Damage=0 Count=64 Slot=26]
]
]

MCPEViz shows the contents of slot1 to slot26 but the parse log shows 27 slots and that slot0 contains 64 of id 0 (air) which I think is what MCPE is barfing on.

0x31-te: [Count] 64 0x40 (byte)
0x31-te: [Damage] 0 0x0 (short)
0x31-te: [Slot] 0 0x0 (byte)
0x31-te: [id] 0 0x0 (short)

Full MCPEViz parse log for the chunk attached as ChestOfDoom.txt

migrated

I have a chest like that too (android), right in the middle of my archive.
Have tried everything to get rid of it as you have, move/break/open/hoppers etc, touch it and MCPE crashes instantly.
I even tried /setblock 1281 66 85 dirt replace and /fill a 9 block cube around it, instant crash.

When I load the world into MCPEViz and check the logs it can read the contents of the chest ok, the log is below but MCPE just cannot handle it at all without crashing.

I expect you'll have to live with it as I have 😞 I feel your pain!!!

overworld-ParsedTileEntity: [Pos=(1282, 66, 85 @ image 3650, 2693) Sign=[Crashes if / opened / DO NOT TOUCH / ]]
overworld-ParsedTileEntity: [
Pos=(1281, 66, 85 @ image 3649, 2693)
Chest=[
[Block:Dirt Damage=0 Count=64 Slot=1]
[Block:Dirt Damage=0 Count=64 Slot=2]
[Block:Dirt Damage=0 Count=64 Slot=3]
[Block:Dirt Damage=0 Count=64 Slot=4]
[Block:Dirt Damage=0 Count=64 Slot=5]
[Block:Dirt Damage=0 Count=64 Slot=6]
[Block:Dirt Damage=0 Count=64 Slot=7]
[Block:Dirt Damage=0 Count=64 Slot=8]
[Block:Dirt Damage=0 Count=64 Slot=9]
[Block:Dirt Damage=0 Count=64 Slot=10]
[Block:Dirt Damage=0 Count=64 Slot=11]
[Block:Dirt Damage=0 Count=64 Slot=12]
[Block:Dirt Damage=0 Count=64 Slot=13]
[Block:Dirt Damage=0 Count=64 Slot=14]
[Block:Dirt Damage=0 Count=64 Slot=15]
[Block:Dirt Damage=0 Count=63 Slot=16]
[Block:Dirt Damage=0 Count=64 Slot=17]
[Block:Dirt Damage=0 Count=64 Slot=18]
[Block:Dirt Damage=0 Count=64 Slot=19]
[Block:Glass Pane Damage=0 Count=16 Slot=20]
[Block:Grass Block Damage=0 Count=8 Slot=21]
[Block:Grass Path Damage=0 Count=1 Slot=22]
[Item:Coal Damage=0 Count=6 Slot=23]
[Block:Dirt Damage=0 Count=64 Slot=24]
[Block:Sandstone, Smooth Damage=2 Count=51 Slot=25]
[Block:Dirt Damage=0 Count=64 Slot=26]
]
]

MCPEViz shows the contents of slot1 to slot26 but the parse log shows 27 slots and that slot0 contains 64 of id 0 (air) which I think is what MCPE is barfing on.

0x31-te: [Count] 64 0x40 (byte)
0x31-te: [Damage] 0 0x0 (short)
0x31-te: [Slot] 0 0x0 (byte)
0x31-te: [id] 0 0x0 (short)

Full MCPEViz parse log for the chunk attached as ChestOfDoom.txt

migrated

I have a chest like that too (android), right in the middle of my archive.
Have tried everything to get rid of it as you have, move/break/open/hoppers etc, touch it and MCPE crashes instantly.
I even tried /setblock 1281 66 85 dirt replace and /fill a 9 block cube around it, instant crash.

When I load the world into MCPEViz and check the logs it can read the contents of the chest ok, the log is below but MCPE just cannot handle it at all without crashing.

I expect you'll have to live with it as I have 😞 I feel your pain!!!

overworld-ParsedTileEntity: [Pos=(1282, 66, 85 @ image 3650, 2693) Sign=[Crashes if / opened / DO NOT TOUCH / ]]
overworld-ParsedTileEntity: [
Pos=(1281, 66, 85 @ image 3649, 2693)
Chest=[
[Block:Dirt Damage=0 Count=64 Slot=1]
[Block:Dirt Damage=0 Count=64 Slot=2]
[Block:Dirt Damage=0 Count=64 Slot=3]
[Block:Dirt Damage=0 Count=64 Slot=4]
[Block:Dirt Damage=0 Count=64 Slot=5]
[Block:Dirt Damage=0 Count=64 Slot=6]
[Block:Dirt Damage=0 Count=64 Slot=7]
[Block:Dirt Damage=0 Count=64 Slot=8]
[Block:Dirt Damage=0 Count=64 Slot=9]
[Block:Dirt Damage=0 Count=64 Slot=10]
[Block:Dirt Damage=0 Count=64 Slot=11]
[Block:Dirt Damage=0 Count=64 Slot=12]
[Block:Dirt Damage=0 Count=64 Slot=13]
[Block:Dirt Damage=0 Count=64 Slot=14]
[Block:Dirt Damage=0 Count=64 Slot=15]
[Block:Dirt Damage=0 Count=63 Slot=16]
[Block:Dirt Damage=0 Count=64 Slot=17]
[Block:Dirt Damage=0 Count=64 Slot=18]
[Block:Dirt Damage=0 Count=64 Slot=19]
[Block:Glass Pane Damage=0 Count=16 Slot=20]
[Block:Grass Block Damage=0 Count=8 Slot=21]
[Block:Grass Path Damage=0 Count=1 Slot=22]
[Item:Coal Damage=0 Count=6 Slot=23]
[Block:Dirt Damage=0 Count=64 Slot=24]
[Block:Sandstone, Smooth Damage=2 Count=51 Slot=25]
[Block:Dirt Damage=0 Count=64 Slot=26]
]
]

MCPEViz shows the contents of slot1 to slot26 but the parse log shows 27 slots and that slot0 contains 64 of id 0 (air) which I think is what MCPE is barfing on.

0x31-te: [Count] 64 0x40 (byte)
0x31-te: [Damage] 0 0x0 (short)
0x31-te: [Slot] 0 0x0 (byte)
0x31-te: [id] 0 0x0 (short)

Full MCPEViz parse log for the chunk attached as ChestOfDoom.txt

migrated

Yea I've just used hoppers to move the inventory into the mountainside out of the way. Seems to be a drop item that causes the crash but only when seen by the player?

migrated

Yea I've just used hoppers to move the inventory into the mountainside out of the way. Seems to be a drop item that causes the crash but only when seen by the player?

migrated

Yea I've just used hoppers to move the inventory into the mountainside out of the way. Seems to be a drop item that causes the crash but only when seen by the player?

migrated

Duplicates MCPE-17783

@Mojang Mods/Helpers
It might be helpful if you update the Guidlines to advise reporters to search and check that a still open issue is not a duplicate before adding a comment to it just as you advise searching before adding a new issue.
I have fallen into this trap a few times now (blush), adding comments to a ticket that has been recently added or updated but has not yet been caught and closed by admin as a duplicate, only to see it resolved as a dupe some time after commenting on it.

migrated

Duplicates MCPE-17783

@Mojang Mods/Helpers
It might be helpful if you update the Guidlines to advise reporters to search and check that a still open issue is not a duplicate before adding a comment to it just as you advise searching before adding a new issue.
I have fallen into this trap a few times now (blush), adding comments to a ticket that has been recently added or updated but has not yet been caught and closed by admin as a duplicate, only to see it resolved as a dupe some time after commenting on it.

migrated

Duplicates MCPE-17783

@Mojang Mods/Helpers
It might be helpful if you update the Guidlines to advise reporters to search and check that a still open issue is not a duplicate before adding a comment to it just as you advise searching before adding a new issue.
I have fallen into this trap a few times now (blush), adding comments to a ticket that has been recently added or updated but has not yet been caught and closed by admin as a duplicate, only to see it resolved as a dupe some time after commenting on it.

migrated

(Unassigned)

Unconfirmed

Windows

1.0.6.52

Retrieved