mojira.dev
MC-311121

Dying and then changing render distance leaks chunks and block entities on the client until the player exits the world or changes dimensions

Steps to Reproduce

  1. Create a new singleplayer world and set render distance to 32.

  2. Stand near an area with block entities within 32 render distance but not within 2, and let chunks finish loading. (Ideally spawnpoint, or move and set spawn there).

  3. Look at root.tick.blockEntities on the piechart, and toggle it off and on to refresh. There should be lots of entries.

  4. Run /kill, then respawn. The respawn point is in the same dimension.

  5. Refresh the pie chart. Entities should still be there.

  6. Without moving, set render distance to 2.

  7. Refresh the pie chart, and the block entities remain, even though they are unloaded.

  8. Save and quit, and rejoin. Refresh the piechart, and see that they are now gone as they should have been in step 7.

Observed Results

The block entities of the discarded chunks keep ticking for the rest of the session.
Waiting, F3 + A, walking away, and raising the render distance back to 32 all fail to clear them. Only a save-quit or a dimension change does.

Expected Results

Chunks the server has stopped tracking are released on the client, and chunks discarded by a render distance change have their block entities unloaded.

Causes

There are 2 causes to this, both can reproduce similar bugs individually, but the main “block entities staying on pie chart when they shouldn’t” can be caused by either.
Cause 1: the server never tells the client to drop the chunks

// PlayerChunkSender.java:44
public void dropChunk(final ServerPlayer player, final ChunkPos pos) {
   if (!this.pendingChunks.remove(pos.pack()) && player.isAlive()) {
      player.connection.send(new ClientboundForgetLevelChunkPacket(pos));
   }
}

Because the player is dead, the chunks around the player fail the isAlive() check, and so those chunks don’t get removed. This only affects chunks far away from the spawn point though, as they will be removed correctly after re-entering and leaving the chunks.

Cause 2: the client leaks block entities when the storage radius shrinks

A client chunk releases its block entities only via ClientLevel.unload, which is what lets Level.tickBlockEntities prune them from Level.blockEntityTickers. Storage.replace and Storage.drop both call it. updateViewRadius does not:

// ClientChunkCache.java:144
for (int i = 0; i < this.storage.chunks.length(); i++) {
   LevelChunk chunk = this.storage.chunks.get(i);
   if (chunk != null) {
      ChunkPos pos = chunk.getPos();
      if (newStorage.inRange(pos.x(), pos.z())) {
         newStorage.replace(newStorage.getIndex(pos.x(), pos.z()), chunk);
      }
      // no else — the chunk is discarded without unload()
   }
}

this.storage = newStorage;

Chunks that do not fit the new window are dropped on the floor along with the old array, so their tickers are never pruned. Nothing can reach them afterwards either: ClientChunkCache.drop(ChunkPos) is gated on storage.inRange, and they are no longer in storage. They are orphaned until ClientLevel is rebuilt, which is why only a relog or a dimension change clears them.

Fix: give the loop an else branch, so discarded chunks take the normal path this.storage.drop(i, chunk).

Attached are 2 reproductions of the bug. The first is showing the steps in the reproduction steps, with dying at spawn and lowering render distance, showing cause 2. The other is with teleporting far away with no trial spawner on piechart, placing one, and dying, with no render distance change, showing cause 1.

Attachments

Comments 4

Thank you for helping us improve Minecraft! We saved your files:

[media][media]

I can’t reproduce using the same method you used in the second video in 26.3 Snapshot 8.

Also, please only upload vanilla recordings, and show the game version in your debug overlay to prove that it is vanilla.

Apologies, here is the same bug reproduced in 26.2 with the debug screen enabled with “vanilla”/”26.2” displayed.

Here it is reproduced in 26.3 - snapshot 8:

It did appear to be location specific. I couldn’t reproduce it by tping to exactly 1000 ~ 1000 either, my guess is that’s due to the Storage wrapping around and replacing the chunk in that slot, and so feeling like the bug was fixed.
Heres also the render distance change with death at spawn which is really easy to reproduce in 26.3 - snapshot 8:

Thanks for replying. I was finally able to reproduce this with both methods. Below is a recording of the teleport method:

I will mark this as Confirmed and add 26.3 Snapshot 8 to the affected versions.

Joel

(Unassigned)

Confirmed

Platform HC

Normal

Networking

26.2, 26.3 Snapshot 8

Retrieved