WinX64
- WinX64
- JIRAUSER706933
- America/Cuiaba
- Yes
- No
MC-242385![[Mojang] Panda](../../../data/avatars/users/41658.png){kind=small}
There seems to be an inconsistency on the calculation of the buffer size on chunk packets. This relates, more specifically, to the following two lines of ClientboundLevelChunkPacketData:
public ClientboundLevelChunkPacketData(LevelChunk chunk) { /* snip */ this.buffer = new byte[calculateChunkSize(chunk)]; extractChunkData(new FriendlyByteBuf(this.getWriteBuffer()), chunk); /* snip */ }As of this issue, the calculation seems to be sometimes resulting in a buffer that is larger than the data that is written to it, generally by a margin of 12~16 bytes on a default vanilla map (see attached image).
After some digging, I narrowed down the problem to these two specific locations. The first one is located at GlobalPalette.
public void read(FriendlyByteBuf buf) { } public void write(FriendlyByteBuf buf) { } public int getSerializedSize() { return FriendlyByteBuf.getVarIntSize(0); }Although nothing is read or written, getSerializedSize still returns the size for a VarInt-encoded zero, which equals 1 byte.
The second one is located at PalettedContainer.Data.
public int getSerializedSize() { return 1 + this.palette.getSerializedSize() + FriendlyByteBuf.getVarIntSize(this.storage.getSize()) + this.storage.getRaw().length * 8; } public void write(FriendlyByteBuf buf) { buf.writeByte(this.storage.getBits()); this.palette.write(buf); buf.writeLongArray(this.storage.getRaw()); }The write method encodes the bits, the palette, and the raw data array, prefixed with its own length. However, getSerializedSize calculates this size prefix using the result from storage.getSize() instead of the raw data array's length. This size doesn't seem to reflect the actual size of the raw data array, and seems to always be either 4096 or 64 (depending if it's a block state or biome palette).
This will always result in an allocation of 2 bytes for the size prefix of the blocks state's raw data array, even if its size encodes to a single byte. Analogously, it will always result in a 1 byte allocation for the biome's raw data array, even if the actual size results in more.Since the client makes no attempt to validate if all the bytes from the buffer were read after receiving the chunk packet, it passes unnoticed, since the buffer always seem to be bigger than the data read. Since there's no validation, I also can't know whether this is intentional or not, but I though I should report anyway.
There seems to be an inconsistency on the calculation of the buffer size on chunk packets. This relates, more specifically, to the following two lines of ClientboundLevelChunkPacketData:
public ClientboundLevelChunkPacketData(LevelChunk chunk) { /* snip */ this.buffer = new byte[calculateChunkSize(chunk)]; extractChunkData(new FriendlyByteBuf(this.getWriteBuffer()), chunk); /* snip */ }As of this issue, the calculation seems to be sometimes resulting in a buffer that is larger than the data that is written to it, generally by a margin of 12~16 bytes on a default vanilla map (see attached image).
After some digging, I narrowed down the problem to these two specific locations. The first one is located at GlobalPalette.public void read(FriendlyByteBuf buf) { } public void write(FriendlyByteBuf buf) { } public int getSerializedSize() { return FriendlyByteBuf.getVarIntSize(0); }
Although nothing is read or written, getSerializedSize still returns the size for a VarInt-encoded zero, which equals 1 byte.The second one is located at PalettedContainer.Data.
public int getSerializedSize() { return 1 + this.palette.getSerializedSize() + FriendlyByteBuf.getVarIntSize(this.storage.getSize()) + this.storage.getRaw().length * 8; } public void write(FriendlyByteBuf buf) { buf.writeByte(this.storage.getBits()); this.palette.write(buf); buf.writeLongArray(this.storage.getRaw()); }The write method encodes the bits, the palette, and the raw data array, prefixed with its own length. However, getSerializedSize calculates this size prefix using the result from storage.getSize() instead of the raw data array's length. This size doesn't seem to reflect the actual size of the raw data array, and seems to always be either 4096 or 64 (depending if it's a block state or biome palette).
This will always result in an allocation of 2 bytes for the size prefix of the blocks state's raw data array, even if its size encodes to a single byte. Analogously, it will always result in a 1 byte allocation for the biome's raw data array, even if the actual size results in more.Since the client makes no attempt to validate if all the bytes from the buffer were read after receiving the chunk packet, it passes unnoticed, since the buffer always seem to be bigger than the data read. Since there's no validation, I also can't know whether this is intentional or not, but I though I should report anyway.
The current implementation of the explosion packet has a disparity between the data that is read from and the data that is written to the network.
More specifically, the part concerning the small and large explosion particles:
net.minecraft.network.protocol.game.ClientboundExplodePacketUnable to find source-code formatter for language: code panel. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yamlpublic ClientboundExplodePacket(FriendlyByteBuf buf) { /* snip */ this.smallExplosionParticles = ClientboundExplodePacket.readParticle(buf, buf.readById(BuiltInRegistries.PARTICLE_TYPE)); this.largeExplosionParticles = ClientboundExplodePacket.readParticle(buf, buf.readById(BuiltInRegistries.PARTICLE_TYPE)); /* snip */ } private static <T extends ParticleOptions> T readParticle(FriendlyByteBuf buf, ParticleType<T> particleType) { return particleType.getDeserializer().fromNetwork(particleType, buf); } @Override public void write(FriendlyByteBuf buf) { /* snip */ buf.writeId(BuiltInRegistries.PARTICLE_TYPE, this.smallExplosionParticles.getType()); buf.writeId(BuiltInRegistries.PARTICLE_TYPE, this.largeExplosionParticles.getType()); /* snip */ }The write logic serializes only the id of the two particles, while the read logic expects the id and whatever extra data is required for the particle (such as colors for the dust particle, block state id for the block particle etc.).
Although there's currently no way to trigger an explosion packet with customized particle types in the Vanilla implementation (only gust and generic types are used as of now), it will break if the behavior is implemented in the future.
Th
is relates to the network registriesthat aresent to the client via ClientboundRegistryDataPacket during the configuration phase,and more specifically to the following registries:
- minecraft:
worldgen/biome;- minecraft:
damage_type;- minecraft:
dimension_type.These registries are used on the client to store the defined biomes, damage types (falling, fire, mobs etc.) and dimensions types (overworld, nether, end etc.). The entries for these registries are then referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes;
- ClientboundDamageEventPacket for damage types;
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types.
However, if an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet. The client will also crash if any of the expected registries themselves haven't been sent (6 different registries as of 1.20.3-pre4).Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material;
- minecraft:trim_pattern;
- minecraft:worldgen/biome;
- minecraft:chat_type;
- minecraft:damage_type;
- minecraft:dimension_type.
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not.
Server not sending all the required registry entries
The client tries to access the registries regardless whether the server sent them, causing it to crash
Server sending references to non-existent registry entries
These registries are used on the client to store the defined biomes, damage types (falling, fire, mobs etc.) and dimensions types (overworld, nether, end etc.). The entries for these registries are then referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes;
- ClientboundDamageEventPacket for damage types;
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types.
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet. The client will also crash if any of the expected registries themselves haven't been sent (6 different registries as of 1.20.3-pre4).
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material;
- minecraft:trim_pattern;
- minecraft:worldgen/biome;
- minecraft:chat_type;
- minecraft:damage_type;
- minecraft:dimension_type.
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not.
Server not sending all the required registry entries
The client tries to access the registries regardless whether the server sent them, causing it to crash
Server sending references to non-existent registry entries
These registries are used on the client to store the defined biomes, damage types (falling, fire, mobs etc.) and dimensions types (overworld, nether, end etc.). The entries for these registries are then referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes;
- ClientboundDamageEventPacket for damage types;
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types.
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet. The client will also crash if any of the expected registries themselves haven't been sent (6 different registries as of 1.20.3-pre4).
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material;
- minecraft:trim_pattern;
- minecraft:worldgen/biome;
- minecraft:chat_type;
- minecraft:damage_type;
- minecraft:dimension_type.
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
The client tries to access the registries regardless whether the server sent them, causing it to crash
Server sending references to non-existent registry entries
These registries are used on the client to store the defined biomes, damage types (falling, fire, mobs etc.) and dimensions types (overworld, nether, end etc.). The entries for these registries are then referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes;
- ClientboundDamageEventPacket for damage types;
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types.
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet. The client will also crash if any of the expected registries themselves haven't been sent (6 different registries as of 1.20.3-pre4).
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material;
- minecraft:trim_pattern;
- minecraft:worldgen/biome;
- minecraft:chat_type;
- minecraft:damage_type;
- minecraft:dimension_type.
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
The client tries to access the registries regardless whether the server sent them, causing it to crash
Server sending references to non-existent registry entries
These registries are used on the client to store the defined biomes, damage types (falling, fire, mobs etc.) and dimensions types (overworld, nether, end etc.). The entries for these registries are then referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes;
- ClientboundDamageEventPacket for damage types;
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types.
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet. The client will also crash if any of the expected registries themselves haven't been sent (6 different registries as of 1.20.3-pre4).
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material;
- minecraft:trim_pattern;
- minecraft:worldgen/biome;
- minecraft:chat_type;
- minecraft:damage_type;
- minecraft:dimension_type.
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
For the minecraft:worldgen/biome and minecraft:damage_type registries, the client expects specific entries to be present, and will try to access them whether they are or not. If they weren't sent by the server, the client crashes.
For minecraft:worldgen/biome, it is the entry by the name of minecraft:plains.
For minecraft:damage_type, they are the entries accessed in the constructor of DamageSources, or the entries by the names of:
- minecraft:in_fire
- minecraft:lightning_bolt
- minecraft:on_fire
- minecraft:lava
- minecraft:hot_floor
- minecraft:in_wall
- minecraft:cramming
- minecraft:drown
- minecraft:starve
- minecraft:cactus
- minecraft:fall
- minecraft:fly_into_wall
- minecraft:out_of_world
- minecraft:generic
- minecraft:magic
- minecraft:wither
- minecraft:dragon_breath
- minecraft:dry_out
- minecraft:sweet_berry_bush
- minecraft:freeze
- minecraft:stalagmite
- minecraft:outside_border
- minecraft:generic_kill
Server sending references to non-existent registry entries
The entries for the minecraft:worldgen/biome, minecraft:damage_type and minecraft:dimension_type registries referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes;
- ClientboundDamageEventPacket for damage types;
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types.
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet:
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material;
- minecraft:trim_pattern;
- minecraft:worldgen/biome;
- minecraft:chat_type;
- minecraft:damage_type;
- minecraft:dimension_type.
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
For the minecraft:worldgen/biome and minecraft:damage_type registries, the client expects specific entries to be present, and will try to access them whether they are or not. If they weren't sent by the server, the client crashes.
For minecraft:worldgen/biome, it is the entry by the name of minecraft:plains.
For minecraft:damage_type, they are the entries accessed in the constructor of DamageSources, or the entries by the names of:
- minecraft:in_fire
- minecraft:lightning_bolt
- minecraft:on_fire
- minecraft:lava
- minecraft:hot_floor
- minecraft:in_wall
- minecraft:cramming
- minecraft:drown
- minecraft:starve
- minecraft:cactus
- minecraft:fall
- minecraft:fly_into_wall
- minecraft:out_of_world
- minecraft:generic
- minecraft:magic
- minecraft:wither
- minecraft:dragon_breath
- minecraft:dry_out
- minecraft:sweet_berry_bush
- minecraft:freeze
- minecraft:stalagmite
- minecraft:outside_border
- minecraft:generic_kill
Server sending references to non-existent registry entries
The entries for the minecraft:worldgen/biome, minecraft:damage_type and minecraft:dimension_type registries referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes;
- ClientboundDamageEventPacket for damage types;
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types.
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet:
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material;
- minecraft:trim_pattern;
- minecraft:worldgen/biome;
- minecraft:chat_type;
- minecraft:damage_type;
- minecraft:dimension_type.
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
For the minecraft:worldgen/biome and minecraft:damage_type registries, the client expects specific entries to be present, and will try to access them whether they are or not. If they weren't sent by the server, the client crashes.
For minecraft:worldgen/biome, it is the entry by the name of minecraft:plains.
For minecraft:damage_type, they are the entries accessed in the constructor of DamageSources, or the entries by the names of:
- minecraft:in_fire
- minecraft:lightning_bolt
- minecraft:on_fire
- minecraft:lava
- minecraft:hot_floor
- minecraft:in_wall
- minecraft:cramming
- minecraft:drown
- minecraft:starve
- minecraft:cactus
- minecraft:fall
- minecraft:fly_into_wall
- minecraft:out_of_world
- minecraft:generic
- minecraft:magic
- minecraft:wither
- minecraft:dragon_breath
- minecraft:dry_out
- minecraft:sweet_berry_bush
- minecraft:freeze
- minecraft:stalagmite
- minecraft:outside_border
- minecraft:generic_kill
Server sending references to non-existent registry entries
The entries for the minecraft:worldgen/biome, minecraft:damage_type and minecraft:dimension_type registries referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes;
- ClientboundDamageEventPacket for damage types;
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types.
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet:
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material;
- minecraft:trim_pattern;
- minecraft:worldgen/biome;
- minecraft:chat_type;
- minecraft:damage_type;
- minecraft:dimension_type.
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
For the minecraft:worldgen/biome and minecraft:damage_type registries, the client expects specific entries to be present, and will try to access them whether they are or not. If they weren't sent by the server, the client crashes.
For minecraft:worldgen/biome, it is the entry by the name of minecraft:plains.
For minecraft:damage_type, they are the entries accessed in the constructor of DamageSources, or the entries by the names of:
- minecraft:in_fire
- minecraft:lightning_bolt
- minecraft:on_fire
- minecraft:lava
- minecraft:hot_floor
- minecraft:in_wall
- minecraft:cramming
- minecraft:drown
- minecraft:starve
- minecraft:cactus
- minecraft:fall
- minecraft:fly_into_wall
- minecraft:out_of_world
- minecraft:generic
- minecraft:magic
- minecraft:wither
- minecraft:dragon_breath
- minecraft:dry_out
- minecraft:sweet_berry_bush
- minecraft:freeze
- minecraft:stalagmite
- minecraft:outside_border
- minecraft:generic_kill
Server sending references to non-existent registry entries
The entries for the minecraft:worldgen/biome, minecraft:damage_type and minecraft:dimension_type registries referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes;
- ClientboundDamageEventPacket for damage types;
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types.
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet:
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material;
- minecraft:trim_pattern;
- minecraft:worldgen/biome;
- minecraft:chat_type;
- minecraft:damage_type;
- minecraft:dimension_type.
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
For the minecraft:worldgen/biome and minecraft:damage_type registries, the client expects specific entries to be present, and will try to access them whether they are or not. If they weren't sent by the server, the client crashes.
For minecraft:worldgen/biome, it is the entry by the name of minecraft:plains.
For minecraft:damage_type, they are the entries accessed in the constructor of DamageSources, or the entries by the names of:
- minecraft:in_fire
- minecraft:lightning_bolt
- minecraft:on_fire
- minecraft:lava
- minecraft:hot_floor
- minecraft:in_wall
- minecraft:cramming
- minecraft:drown
- minecraft:starve
- minecraft:cactus
- minecraft:fall
- minecraft:fly_into_wall
- minecraft:out_of_world
- minecraft:generic
- minecraft:magic
- minecraft:wither
- minecraft:dragon_breath
- minecraft:dry_out
- minecraft:sweet_berry_bush
- minecraft:freeze
- minecraft:stalagmite
- minecraft:outside_border
- minecraft:generic_kill
Server sending references to non-existent registry entries
The entries for the minecraft:worldgen/biome, minecraft:damage_type and minecraft:dimension_type registries referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes;
- ClientboundDamageEventPacket for damage types;
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types.
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet:
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material;
- minecraft:trim_pattern;
- minecraft:worldgen/biome;
- minecraft:chat_type;
- minecraft:damage_type;
- minecraft:dimension_type.
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
For the minecraft:worldgen/biome and minecraft:damage_type registries, the client expects specific entries to be present, and will try to access them whether they are or not. If they weren't sent by the server, the client crashes.
For minecraft:worldgen/biome, it is the entry by the name of minecraft:plains.
For minecraft:damage_type, they are the entries accessed in the constructor of DamageSources, or the entries by the names of:
- minecraft:in_fire
- minecraft:lightning_bolt
- minecraft:on_fire
- minecraft:lava
- minecraft:hot_floor
- minecraft:in_wall
- minecraft:cramming
- minecraft:drown
- minecraft:starve
- minecraft:cactus
- minecraft:fall
- minecraft:fly_into_wall
- minecraft:out_of_world
- minecraft:generic
- minecraft:magic
- minecraft:wither
- minecraft:dragon_breath
- minecraft:dry_out
- minecraft:sweet_berry_bush
- minecraft:freeze
- minecraft:stalagmite
- minecraft:outside_border
- minecraft:generic_kill
Server sending references to non-existent registry entries
The entries for the minecraft:worldgen/biome, minecraft:damage_type and minecraft:dimension_type registries referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes;
- ClientboundDamageEventPacket for damage types;
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types.
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet:
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
Client crashes when receivingreferences to non-existent entries ofnetwork registriesClient crashes when receiving inconsistent network registries
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material;
- minecraft:trim_pattern;
- minecraft:worldgen/biome;
- minecraft:chat_type;
- minecraft:damage_type;
- minecraft:dimension_type.
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
For the minecraft:worldgen/biome and minecraft:damage_type registries, the client expects specific entries to be present, and will try to access them whether they are or not. If they weren't sent by the server, the client crashes.
For minecraft:worldgen/biome, it is the entry by the name of minecraft:plains.
For minecraft:damage_type, they are the entries accessed in the constructor of DamageSources, or the entries by the names of:
- minecraft:in_fire
- minecraft:lightning_bolt
- minecraft:on_fire
- minecraft:lava
- minecraft:hot_floor
- minecraft:in_wall
- minecraft:cramming
- minecraft:drown
- minecraft:starve
- minecraft:cactus
- minecraft:fall
- minecraft:fly_into_wall
- minecraft:out_of_world
- minecraft:generic
- minecraft:magic
- minecraft:wither
- minecraft:dragon_breath
- minecraft:dry_out
- minecraft:sweet_berry_bush
- minecraft:freeze
- minecraft:stalagmite
- minecraft:outside_border
- minecraft:generic_kill
Server sending references to non-existent registry entries
The entries for the minecraft:worldgen/biome, minecraft:damage_type and minecraft:dimension_type registries referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes
;- ClientboundDamageEventPacket for damage types
;- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types
.If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet:
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material
- minecraft:trim_pattern
- minecraft:worldgen/biome
- minecraft:chat_type
- minecraft:damage_type
- minecraft:dimension_type
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
For the minecraft:worldgen/biome and minecraft:damage_type registries, the client expects specific entries to be present, and will try to access them whether they are or not. If they weren't sent by the server, the client crashes.
For minecraft:worldgen/biome, it is the entry by the name of minecraft:plains.
For minecraft:damage_type, they are the entries accessed in the constructor of DamageSources, or the entries by the names of:
- minecraft:in_fire
- minecraft:lightning_bolt
- minecraft:on_fire
- minecraft:lava
- minecraft:hot_floor
- minecraft:in_wall
- minecraft:cramming
- minecraft:drown
- minecraft:starve
- minecraft:cactus
- minecraft:fall
- minecraft:fly_into_wall
- minecraft:out_of_world
- minecraft:generic
- minecraft:magic
- minecraft:wither
- minecraft:dragon_breath
- minecraft:dry_out
- minecraft:sweet_berry_bush
- minecraft:freeze
- minecraft:stalagmite
- minecraft:outside_border
- minecraft:generic_kill
Server sending references to non-existent registry entries
The entries for the minecraft:worldgen/biome, minecraft:damage_type and minecraft:dimension_type registries are referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes
- ClientboundDamageEventPacket for damage types
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet:
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material
- minecraft:trim_pattern
- minecraft:worldgen/biome
- minecraft:chat_type
- minecraft:damage_type
- minecraft:dimension_type
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
For the minecraft:worldgen/biome and minecraft:damage_type registries, the client expects specific entries to be present, and will try to access them whether they are or not. If they weren't sent by the server, the client crashes.
For minecraft:worldgen/biome, it is the entry by the name of minecraft:plains.
For minecraft:damage_type, they are the entries accessed in the constructor of DamageSources, or the entries by the names of:
- minecraft:in_fire
- minecraft:lightning_bolt
- minecraft:on_fire
- minecraft:lava
- minecraft:hot_floor
- minecraft:in_wall
- minecraft:cramming
- minecraft:drown
- minecraft:starve
- minecraft:cactus
- minecraft:fall
- minecraft:fly_into_wall
- minecraft:out_of_world
- minecraft:generic
- minecraft:magic
- minecraft:wither
- minecraft:dragon_breath
- minecraft:dry_out
- minecraft:sweet_berry_bush
- minecraft:freeze
- minecraft:stalagmite
- minecraft:outside_border
- minecraft:generic_kill
Server sending references to non-existent registry entries
The entries for the minecraft:worldgen/biome, minecraft:damage_type and minecraft:dimension_type registries are referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes
- ClientboundDamageEventPacket for damage types
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet:
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material
- minecraft:trim_pattern
- minecraft:worldgen/biome
- minecraft:chat_type
- minecraft:damage_type
- minecraft:dimension_type
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
For the minecraft:worldgen/biome and minecraft:damage_type registries, the client expects specific entries to be present, and will try to access them whether they are or not. If they weren't sent by the server, the client crashes.
For minecraft:worldgen/biome, it is the entry by the name of minecraft:plains.
For minecraft:damage_type, they are the entries accessed in the constructor of DamageSources, or the entries by the names of:
- minecraft:in_fire
- minecraft:lightning_bolt
- minecraft:on_fire
- minecraft:lava
- minecraft:hot_floor
- minecraft:in_wall
- minecraft:cramming
- minecraft:drown
- minecraft:starve
- minecraft:cactus
- minecraft:fall
- minecraft:fly_into_wall
- minecraft:out_of_world
- minecraft:generic
- minecraft:magic
- minecraft:wither
- minecraft:dragon_breath
- minecraft:dry_out
- minecraft:sweet_berry_bush
- minecraft:freeze
- minecraft:stalagmite
- minecraft:outside_border
- minecraft:generic_kill
Server sending references to non-existent registry entries
The entries for the minecraft:worldgen/biome, minecraft:damage_type and minecraft:dimension_type registries are referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes
- ClientboundDamageEventPacket for damage types
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet:
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material
- minecraft:trim_pattern
- minecraft:worldgen/biome
- minecraft:chat_type
- minecraft:damage_type
- minecraft:dimension_type
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
For the minecraft:worldgen/biome and minecraft:damage_type registries, the client expects specific entries to be present, and will try to access them whether they are or not. If they weren't sent by the server, the client crashes.
For minecraft:worldgen/biome, it is the entry by the name of minecraft:plains.
For minecraft:damage_type, they are the entries accessed in the constructor of DamageSources, or the entries by the names of:
- minecraft:in_fire
- minecraft:lightning_bolt
- minecraft:on_fire
- minecraft:lava
- minecraft:hot_floor
- minecraft:in_wall
- minecraft:cramming
- minecraft:drown
- minecraft:starve
- minecraft:cactus
- minecraft:fall
- minecraft:fly_into_wall
- minecraft:out_of_world
- minecraft:generic
- minecraft:magic
- minecraft:wither
- minecraft:dragon_breath
- minecraft:dry_out
- minecraft:sweet_berry_bush
- minecraft:freeze
- minecraft:stalagmite
- minecraft:outside_border
- minecraft:generic_kill
Server sending references to non-existent registry entries
The entries for the minecraft:worldgen/biome, minecraft:damage_type and minecraft:dimension_type registries are referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes
- ClientboundDamageEventPacket for damage types
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet:
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
The network registries compose the data that is sent to the client via ClientboundRegistryDataPacket during the configuration phase, the six of them being:
- minecraft:trim_material
- minecraft:trim_pattern
- minecraft:worldgen/biome
- minecraft:chat_type
- minecraft:damage_type
- minecraft:dimension_type
There are currently three issues with how they are handled on the client, all of them causing it to crash. They are as follows:
Server not sending all the required registries
The client will attempt to access every one of the six registries, regardless if they were sent by the server or not. If the registry wasn't sent by the server, the client crashes:
Server not sending all the required registry entries
For the minecraft:worldgen/biome and minecraft:damage_type registries, the client expects specific entries to be present, and will try to access them whether they are or not. If they weren't sent by the server, the client crashes.
For minecraft:worldgen/biome, it is the entry by the name of minecraft:plains.
For minecraft:damage_type, they are the entries accessed in the constructor of DamageSources, or the entries by the names of:
- minecraft:in_fire
- minecraft:lightning_bolt
- minecraft:on_fire
- minecraft:lava
- minecraft:hot_floor
- minecraft:in_wall
- minecraft:cramming
- minecraft:drown
- minecraft:starve
- minecraft:cactus
- minecraft:fall
- minecraft:fly_into_wall
- minecraft:out_of_world
- minecraft:generic
- minecraft:magic
- minecraft:wither
- minecraft:dragon_breath
- minecraft:dry_out
- minecraft:sweet_berry_bush
- minecraft:freeze
- minecraft:stalagmite
- minecraft:outside_border
- minecraft:generic_kill
Server sending references to non-existent registry entries
The entries for the minecraft:worldgen/biome, minecraft:damage_type and minecraft:dimension_type registries are referenced in other parts of the protocol, namely the following packets:
- ClientboundChunksBiomesPacket and ClientboundLevelChunkWithLightPacket for biomes
- ClientboundDamageEventPacket for damage types
- ClientboundLoginPacket and ClientboundRespawnPacket for dimension types
If an entry that isn't present in the network registries is referenced in any of the packets above, the client will crash upon receiving said packet:
Conversely, a similar situation happens with the minecraft:chat_type registry and both ClientboundDisguisedChatPacket and ClientboundPlayerChatPacket packets. However, the client instead disconnects gracefully from the server with a multiplayer.disconnect.invalid_packet message instead of hard crashing, which was perhaps the intended behavior for the others?
As far as I am aware, these situations will never happen with the Vanilla server, but only with a modded one where the registries have been specifically crafted. It does however, always affect and crash the Vanilla client regardless.
Seems to have been fixed in 23w31a.
The first problem (GlobalPallete) was recently fixed on 23w31a, but the second (PalettedContainer.Data) still remains.
Made the issue more generalized, tackling two closely related problems regarding the network registries.
Added the crash-logs for each case. They could be relevant as the crashes were triggered in six distinct parts of the code.
I am no longer able to reproduce any of the crashes as of 1.20.5-pre2. All the scenarios described in this issue now lead to a client disconnect with either a Failed to decode packet '<packet>' (during packet decoding) or disconnect.packetError (during packet processing) message.