Large numbers of scheduled instant updates crashes the game
Large numbers of scheduled instant updates crash the game. There are multiple ways to reproduce this, however doing /fill is the easiest.
Steps to reproduce:
- do /fill ~~~ ~15 ~15 ~15 flower_pot (or any other block that uses instant updates)
- make sure the fill command doesn't cross a chunk border, since instant updates from commands ignore other chunks
- the game will crash
Explanation:
/fill commands place the blocks first and then processes the updates later.
This means that the instant updates are chained and this chain results in lots of instant updates being scheduled and the game crashing, probably because of a stack overflow error.
This is similar to what happens in java.
It can result in lots of unnecessary crashes when using commands and could be used to crash a server in survival as well.
This cannot simply be fixed by making everything use pendingTicks, since that is simply not possible for blocks like doors, beds and portal tiles without adding some dupe glitches or wierd behaviour.
Created Issue:
Large numbers of scheduled instant updates crashes the game
Large numbers of scheduled instant updates crash the game. There are multiple ways to reproduce this, however doing /fill is the easiest.
Steps to reproduce:
- do /fill ~~~ ~15 ~15 ~15 flower_pot (or any other block that uses instant updates)
- make sure the fill command doesn't cross a chunk border, since instant updates from commands ignore other chunks
- the game will crash
Explanation:
/fill commands place the blocks first and then processes the updates later.
This means that the instant updates are chained and this chain results in lots of instant updates being scheduled and the game crashing.This is kinda similar to what happens in java.
It can result in lots of unnecessary crashes when using commands and could potentially be used to crash a server in pure survival mode.
Large numbers of scheduled instant updates crash the game. There are multiple ways to reproduce this, however doing /fill is the easiest.
Steps to reproduce:
- do /fill ~~~ ~15 ~15 ~15 flower_pot (or any other block that uses instant updates)
- make sure the fill command doesn't cross a chunk border, since instant updates from commands ignore other chunks
- the game will crash
Explanation:
/fill commands place the blocks first and then processes the updates later.
This means that the instant updates are chained and this chain results in lots of instant updates being scheduled and the game crashing.This is kinda similar to what happens in java.
It can result in lots of unnecessary crashes when using commands and could
potentiallybe used to crash a server inpuresurvivalmode.Large numbers of scheduled instant updates crash the game. There are multiple ways to reproduce this, however doing /fill is the easiest.
Steps to reproduce:
- do /fill ~~~ ~15 ~15 ~15 flower_pot (or any other block that uses instant updates)
- make sure the fill command doesn't cross a chunk border, since instant updates from commands ignore other chunks
- the game will crash
Explanation:
/fill commands place the blocks first and then processes the updates later.
This means that the instant updates are chained and this chain results in lots of instant updates being scheduled and the game crashing.This is kinda similar to what happens in java.
It can result in lots of unnecessary crashes when using commands and could be used to crash a server in survival as well.
Large numbers of scheduled instant updates crash the game. There are multiple ways to reproduce this, however doing /fill is the easiest.
Steps to reproduce:
- do /fill ~~~ ~15 ~15 ~15 flower_pot (or any other block that uses instant updates)
- make sure the fill command doesn't cross a chunk border, since instant updates from commands ignore other chunks
- the game will crash
Explanation:
/fill commands place the blocks first and then processes the updates later.
This means that the instant updates are chained and this chain results in lots of instant updates being scheduled and the game crashing, probably because of a stack overflow error.This is kinda similar to what happens in java.
It can result in lots of unnecessary crashes when using commands and could be used to crash a server in survival as well.
Large numbers of scheduled instant updates crash the game. There are multiple ways to reproduce this, however doing /fill is the easiest.
Steps to reproduce:
- do /fill ~~~ ~15 ~15 ~15 flower_pot (or any other block that uses instant updates)
- make sure the fill command doesn't cross a chunk border, since instant updates from commands ignore other chunks
- the game will crash
Explanation:
/fill commands place the blocks first and then processes the updates later.
This means that the instant updates are chained and this chain results in lots of instant updates being scheduled and the game crashing, probably because of a stack overflow error.This is
kindasimilar to what happens in java.It can result in lots of unnecessary crashes when using commands and could be used to crash a server in survival as well.
Large numbers of scheduled instant updates crash the game. There are multiple ways to reproduce this, however doing /fill is the easiest.
Steps to reproduce:
- do /fill ~~~ ~15 ~15 ~15 flower_pot (or any other block that uses instant updates)
- make sure the fill command doesn't cross a chunk border, since instant updates from commands ignore other chunks
- the game will crash
Explanation:
/fill commands place the blocks first and then processes the updates later.
This means that the instant updates are chained and this chain results in lots of instant updates being scheduled and the game crashing, probably because of a stack overflow error.This is similar to what happens in java.
It can result in lots of unnecessary crashes when using commands and could be used to crash a server in survival as well.
This cannot simply be fixed by making everything use pendingTicks, since that is simply not possible for blocks like doors, beds and portal tiles without adding some dupe glitches or wierd behaviour.
relates to
relates to
The change to portal tile behavior is quite inexplicable from the player community's point of of view. The stated reason for the change in the 1.16.100.55 changelog is that filling a large area with portal tiles at once with a /fill command could cause a crash.
Fixed crash when using /fill command with Portal to fill huge amount of blocks
This sure sounds like just a special case of MCPE-94942, which is reproducible with a number of blocks. There is no apparent reason why portal tiles were singled out for a special fix attempt. Moreover, the description of MCPE-94942 had already pointed out that
This cannot simply be fixed by making everything use pendingTicks, since that is simply not possible for blocks like doors, beds and portal tiles without adding some dupe glitches or wierd behaviour.
(emphasis added)
The English names for the blocks mentioned are: observers, dispensers, droppers, and redstone lamps.
The behavior described is a result of Bedrock Edition's pendingTick cap. Pending ticks are a kind of pre-scheduled block update. The game will execute a maximum of 100 pending ticks in each chunk during each game tick.
Other blocks that use pending ticks include detector rails, portal tiles (when spawning zombified piglins after a portal is lit), and water and lava spreading.
I expect the described behavior is working as intended because the pending tick cap serves to prevent processing overload that could crash the game or corrupt chunk data. (See for example MCPE-94942.)
Note: this doesn't happen when using something like buttons, since they break using pending ticks and you don't get the chained instant updates, meaning that this is definitely not related to lag.
Also, last time I checked, blocks were updated in the following order from instant updates:
x- x+ z+ z- y+ y-
This might be useful while testing stuff.