BugTracker_

Can confirm in 26.2 Pre-Release 2.

I was able to confirm this as of 26.1.2, the easiest approach to confirming this is by either using a bot framework or having a populated server.

Steps to Reproduce (bash commands):

1 - Set up a Minecraft vanilla server and edit server.properties:

enable-query=true
query.port=25565
online-mode=false
max-players=200
view-distance=2
simulation-distance=2
enable-rcon=false
motd=test

2 - Install the Rust bot framework (azalea) inside the server

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --default-toolchain nightly
source ~/.cargo/env

3 - Create the bot project:

mkdir ~/mcbots && cd ~/mcbots && cargo init

4 - Write the Cargo.toml file:

[package]
name = "mcbots"
version = "0.1.0"
edition = "2021"

[dependencies]
azalea = { git = "https://github.com/azalea-rs/azalea" }
tokio = { version = "1", features = ["full"] }
anyhow = "1"

5 - Write the bot:

use azalea::prelude::*;
use azalea::swarm::prelude::*;

#[derive(Default, Clone, Component)]
struct State;

#[derive(Default, Clone, Resource)]
struct SwarmState;

#[tokio::main]
async fn main() {
    let accounts: Vec<Account> = (0..150u32)
        .map(|i| Account::offline(&format!("BotFace{:04}", i)))
        .collect();

    SwarmBuilder::new()
        .set_handler(handle)
        .set_swarm_handler(swarm_handler)
        .add_accounts(accounts)
        .start("127.0.0.1")
        .await;
}

async fn handle(_bot: Client, _event: Event, _state: State) -> anyhow::Result<()> {
    Ok(())
}

async fn swarm_handler(_swarm: Swarm, _event: SwarmEvent, _state: SwarmState) -> anyhow::Result<()> {
    Ok(())
}

6 - Start the server

7 - Build the bots:

cargo build --release 2>&1 | tail -5

8 - Run the bots:

~/mcbots/target/release/mcbots &
sleep 20 && grep -c "logged in" ~/mcserver/server.log

9 - Create the query script:

import socket, struct

def query(host, port):
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    s.settimeout(5)
    s.sendto(b'\xFE\xFD\x09\x00\x00\x00\x01', (host, port))
    challenge_data, _ = s.recvfrom(1024)
    challenge = struct.pack('>i', int(challenge_data[5:-1]))
    payload = b'\xFE\xFD\x00\x00\x00\x00\x01' + challenge + b'\x00\x00\x00\x00'
    s.sendto(payload, (host, port))
    response = b''
    while True:
        try:
            chunk, _ = s.recvfrom(4096)
            response += chunk
        except socket.timeout:
            break
    s.close()
    print(f"Total response size: {len(response)} bytes")
    print(f"Exceeds MTU (1500): {len(response) > 1500}")
    return response

query('127.0.0.1', 25565)

10 - Run the query script:

python3 ~/query.py

Output:

Total response size: 1969 bytes
Exceeds MTU (1500): True

Can confirm in 26.1.2.

Can confirm.

The previous attached datapack did not display the action bar/title, fixed datapack:

Can confirm in 1.21.11, datapack:

How to Reproduce:

• Run the following command:

  /give @s minecraft:bow[minecraft:custom_data={'xclib:run_command':{inventory_change:{enable:true,command:"say 3"}}}]

• Drop the given bow, observe how no title appears and no sound plays.

Can confirm in 1.21.11.

This is still present in 1.21.11, GoalSelector.a(boolean) (goalTick) iterates this.c via for each and calls WrappedGoal.tick() ($$2.a()) on each running goal. SkeletonTrapGoal.tick() calls setTrap(false) (this.a.x(false)) mid iteration. setTrap(false) calls removeGoal() (this.cs.a(this.cv)), which calls removeIf directly on this.c, the set currently being iterated:

for (cqe $$2 : this.c) {
    if (!$$2.h() || !$$0 && !$$2.X_()) continue;
    $$2.a();
}

public void a() {
    axf $$0 = (axf)this.a.ao();
    cda $$1 = $$0.c(this.a.dK());
    this.a.x(false);
    ...
}

public void x(boolean $$0) {
    if ($$0 == this.cB) {
        return;
    }
    this.cB = $$0;
    if ($$0) {
        this.cs.a(1, this.cv);
    } else {
        this.cs.a(this.cv);
    }
}

public void a(cop $$0) {
    for (cqe $$12 : this.c) {
        if ($$12.k() != $$0 || !$$12.h()) continue;
        $$12.e();
    }
    this.c.removeIf($$1 -> $$1.k() == $$0);
}

private final Set<cqe> c = new ObjectLinkedOpenHashSet();

However, based on my analysis, it is worth noting that the structural difference from the original report: this.c is now ObjectLinkedOpenHashSet (fastutil) rather than java.util.LinkedHashSet. The original safe in vanilla assumption relied on LinkedHashSet's iterator only checking modCount in next(), not hasNext(). With ObjectLinkedOpenHashSet, modification during for each iteration produces undefined behavior rather than a guaranteed CME.

This seems to have been fixed in 25w44a:

Prior versions:

I cannot reproduce this anymore, it seems to have been fixed in 22w12a:

Prior versions:

This is still an issue as of 1.21.11, this can be confirmed via datapacks:

How to Reproduce

• /summon skeleton ~ ~ ~3

• Let it attack you, test A + B will trigger

• /advancement revoke @s everything

• Get blown up by a creeper, test D triggers, C does not

Clarification

If Test C never triggers under any circumstance, it proves both source_entity fields check the same entity, making the condition impossible (nothing can be both a skeleton and a creeper simultaneously). That's the definitive proof the fields are duplicated and redundant.

This is still an issue as of 1.21.11.

How to Reproduce / Updated Commands:

/setblock ~ ~ ~ minecraft:spawner

/data merge block ~ ~ ~ {SpawnData:{entity:{id:"minecraft:armor_stand",CustomName:'{"text":"SpawnData"}',CustomNameVisible:1b}},SpawnPotentials:[{weight:1,data:{entity:{id:"minecraft:armor_stand",CustomName:'{"text":"SpawnPotentials"}',CustomNameVisible:1b}}}]}

Steps:

• Wait for the spawner to spawn an armor stand

• Right click the spawner with a Sheep spawn egg

• Inspect NBT with /data get block ~ ~ ~

Result:

SpawnData: {entity: {CustomName: '{"text":"SpawnPotentials"}', id: "minecraft:sheep", CustomNameVisible: 1b}}
SpawnPotentials: [{data: {entity: {CustomName: '{"text":"SpawnPotentials"}', id: "minecraft:sheep", CustomNameVisible: 1b}}, weight: 1}]

This is still an issue as of 1.21.11:

Affects 1.21.11, this can be verified by examining the game's asset files directly.

In sounds.json, sound events reference subtitle translation keys via the "subtitle" field. These keys are never namespaced:

"block.chest.open": { "subtitle": "subtitles.block.chest.open" }
"block.honey_block.slide": { "subtitle": "subtitles.block.honey_block.slide" }
"entity.pig.ambient": { "subtitle": "subtitles.entity.pig.ambient" }
"entity.creeper.primed": { "subtitle": "subtitles.entity.creeper.primed" }
"item.bucket.fill": { "subtitle": "subtitles.item.bucket.fill" }

In en_us.json, the subtitle translation keys are defined without any namespace:

"subtitles.block.chest.open": "Chest opens",
"subtitles.block.honey_block.slide": "Sliding down a honey block",
"subtitles.entity.pig.ambient": "Pig oinks",
"subtitles.entity.creeper.primed": "Creeper hisses",
"subtitles.item.bucket.fill": "Bucket fills"

Compare this to how every other translation category in the same en_us.json consistently embeds the "minecraft" namespace:

"block.minecraft.chest": "Chest",
"block.minecraft.honey_block": "Honey Block",
"entity.minecraft.pig": "Pig",
"entity.minecraft.creeper": "Creeper",
"item.minecraft.bucket": "Bucket"

Out of 968 subtitle keys in en_us.json, zero contain the "minecraft" namespace. Meanwhile, categories like block (1,854 keys), item (755 keys), entity (213 keys), biome (65 keys), effect (40 keys), and enchantment (44 keys) all consistently use it.

This has been fixed in 25w44a:

Prior versions:

Can confirm as well.

Affects 1.21.11, updated datapack:

Affects 1.21.11, updated datapack:

This no longer seems to be an issue as of 1.21.11:

running is not volatile

The field is explicitly declared:

protected volatile boolean a;

Full memory visibility is guaranteed between the main thread writing this.a = false in stop() and the background thread reading it in while (this.a).

stop() calls non-thread-safe methods on timeout

Every method called after join() times out, isAlive(), getState(), and interrupt() are JDK Thread primitives explicitly designed by the Java specification for cross thread invocation.

public synchronized void b() {
    this.a = false;
    ...
    this.c.interrupt();
    ...
    this.c = null;
}

Can confirm in 1.21.11, the obfuscated class bcs maps to RconClient and the faulty constructor is still present and unchanged.

bcs(ank $$0, String $$1, Socket $$2) {
    super("RCON Client " + String.valueOf($$2.getInetAddress()));
    ...
}

The run() method handles RCON login packet type 3 and compares against a password field, perfectly matching the known RconClient protocol behavior.

bcs(ank $$0, String $$1, Socket $$2) {
    super("RCON Client " + String.valueOf($$2.getInetAddress()));
    this.n = $$0;
    this.k = $$2;
    try {
        this.k.setSoTimeout(0);
    }
    catch (Exception $$3) {
        this.a = false;
    }
    this.m = $$1;
}

this.a is already false by default and gets overwritten to true on start():

public abstract class bcq implements Runnable {
    protected volatile boolean a;
    
    public synchronized boolean a() {
        if (this.a) return true;
        this.a = true;
        this.c = new Thread(this, this.b + " #" + e.incrementAndGet());
        this.c.start();
        return true;
    }
}