TerrorBite

Yes, the specific race condition used as an example in this bug report occurs in the entity processing code. Rcon commands that manipulate entities will cause a crash when the server is also processing entities at the same time, since Rcon and the server operate on different threads. If there are no players on the server and thus few or no entities are loaded, the server will be spending little or no time processing entities, avoiding the race condition.

However, entity processing is only one area that is affected by the root cause of the issue, that cause being the Rcon thread modifying server data in a non-thread-safe manner. As @jonathan2520 has discovered, a crash will also occur if the server thread is handling block updates for water flows while Rcon commands are also trying to modify blocks. This has nothing to do with entities, but the cause of the crash is ultimately the same.

Ultimately, the fix for this bug must involve one of two solutions: Either

1. utilizing locks with critical Minecraft data structures, to prevent concurrent modification, or

2. pushing Rcon commands into a queue from where they will be popped by the server thread, so that ultimately the commands are run on the server thread.

This issue is confirmed to affect 1.10.2. Crash report attached. Server log attached.

During reproduction of this bug using the attached rcon.py script, it was observed that introducing a small delay (as low as 0.003 seconds) between commands appears to greatly reduce the chance-per-summon of the bug being triggered. However, with zero delay between commands being sent, the chance of the bug being triggered is significant, with usually less than 100 entities being successfully summoned before the crash occurs.

The current test script summons 20 snowballs every 2 seconds, meaning the server usually crashes within 10 seconds of the script being started.

Updated rcon.py test script that uses snowballs instead of fireballs (due to some changes to entity handling that cause summoned fireballs to vanish before they spawn)

It is unlikely this bug will be fixed without special attention, since the observed behaviour is an artifact of the way that Rcon has been implemented (as a separate listener thread). The only way to resolve the issue is to implement special handling of Rcon commands by queueing them for the main thread to handle (and likely blocking the Rcon thread until the result of the command is available), rather than naively executing them directly on the Rcon thread where they can interfere with concurrent operations on the main server thread.

@@unknown: Under MC-72390, I have a PoC script that is tested and, via Rcon, will crash a server with a ConcurrentModificationException; though I'm not sure if that bug is caused by this one. They're almost certainly related, however.

@@unknown: do you have further details about how this issue relates to MC-72390?

Related to MC-72390

This should now be considered a child bug of MC-72390

This is a duplicate of MC-72390

This should not duplicate MC-77255, since 77255 is caused by the Watchdog, not by Rcon.

This appears to be a duplicate of MC-72390

It's been over a year since this bug was reported, and the issue persists. It's perhaps worth noting that a popular third-party server project fixed this same issue over three years ago.

This is emergent behaviour due to the way that lava sets flammable blocks on fire.

There is a specific area of blocks above a lava source, namely the 3x3 directly above the lava block, and 5x5 on the next layer up: http://i.stack.imgur.com/1vNGB.png (Fire blocks have a similar area, but it is a different shape)

In technical terms, any air block in this area, which has a flammable block beside it, will be converted to a fire block when it receives a random tick (note that the flammable block does not have to be within this area).

Now, looking at your screenshot:

Comparing this to the valid set of flammable blocks, you will note that none of the wood blocks in your screenshot are next to a block that is valid to become fire. Also note that the top surface of the logs are covered by flowing lava, so they are not valid to become fire blocks.

I am not certain on the rules here, but I believe flowing lava will not set flammable blocks on fire, except for falling lava (created when flowing lava drops down one block - this is why breaking a wood block and letting the lava flow down will set the wood on fire).

In conclusion, I'm going to say that this behaviour, while counter-intuitive, is by design.

Thanks for the info!

@Amn3zik Out of interest, what were you attempting to do via Rcon that triggered that crash?

Attached crash report generated by reproducing the bug using rcon.py

Attached Python script used to reproduce the bug. Connects to Rcon on port 25575 with password "test" and issues a rapid series of /summon Fireball commands (server despawns the fireballs immediately).

Looks like these are only warnings, not errors. While it is unusual for these messages to show up, it appears that the game is detecting a potential issue (buffer too small) and resolving it (growing the buffer), so overall there is no problem.

Do you have your view distance set to a very high value, such as 15 or higher? Do the messages stop if you lower your view distance?

Can confirm this issue exists in Minecraft 1.8 running on Java 8. I can also confirm that this is a long-standing issue: I originally reported this bug for Minecraft 1.3.2, see BUKKIT-2546.

Related: MC-46850

[12:40:09 INFO]: [STDERR]@.(null:-1): java.util.ConcurrentModificationException
[12:40:09 INFO]: [STDERR]@.(null:-1):   at java.util.TreeMap$AbstractMapIterator.makeNext(TreeMap.java:200)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at java.util.TreeMap$UnboundedKeyIterator.next(TreeMap.java:269)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at qt.a(SourceFile:575)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at qt.a(SourceFile:555)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at bfy.a(SourceFile:258)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at bfy.a(SourceFile:113)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at qs.b(SourceFile:160)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at qs.a(SourceFile:203)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at qt.a(SourceFile:767)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at cg.a(SourceFile:37)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at ab.a(ab.java:120)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at ab.a(ab.java:94)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at net.minecraft.server.MinecraftServer.g(SourceFile:789)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at th.run(SourceFile:80)
[12:40:09 INFO]: [STDERR]@.(null:-1):   at java.lang.Thread.run(Unknown Source)
[12:40:09 INFO]: [Rcon: Saved the world]

It appears that qt.a(boolean) is not threadsafe, and modifies world data structures while the Rcon thread is attempting to read the same structures to save the world.

Confirming this is still an issue in Minecraft 1.7.2 and with 1.7.4 client on 1.7.2 server. Have not tested with 1.7.4 server.

@Grum
Was this fixed for more than just player nameplates? I notice that related issues are also fixed.

For example, if color codes are used in a kick message, the text is now properly center-justified, whereas it would previously be incorrectly offset. Colored text on signs is also now centered correctly.

Either way, thanks for the fix!