Server crash

[nyvlunx]

Link/paste of stack trace

https://pastebin.com/W7PMG8Zy

Plugin list:

Plugins (35): ArmorStandEditor, BKCommonLib, BuildersUtilities, BungeeTabListPlus, CoreProtect, CraftingStore, Denizen, Depenizen, DiscordSRV, Essentials, EssentialsAntiBuild, EssentialsChat, EssentialsProtect, EssentialsSpawn, FastAsyncWorldEdit, goBrush, goPaint, HeadDatabase, HeadDisplays, HolographicDisplays, IPWhitelist, LightCleaner, Multiverse-Core, Plan, PlotSquared, spark, Vault, ViaBackwards, ViaVersion, VoxelSniper, WorldBorder, WorldEdit, WorldEditSelectionVisualizer, WorldGuard, zPermissions

Paper build number:

Paper version git-Paper-283 (MC: 1.15.2) (Implementing API version 1.15.2-R0.1-SNAPSHOT)

[MiniDigger]

plotsquared caused a deadlock somehow. you should report there.

[dordsor21]

Technically FAWE, also the code in question is the following method:

    public static Chunk ensureLoaded(World nmsWorld, int X, int Z) {
        Chunk nmsChunk = nmsWorld.getChunkIfLoaded(X, Z);
        if (nmsChunk != null) {
            return nmsChunk;
        }
        if (Fawe.isMainThread()) {
            return nmsWorld.getChunkAt(X, Z);
        }
        if (PaperLib.isPaper()) {
            CraftWorld craftWorld = nmsWorld.getWorld();
            CompletableFuture<org.bukkit.Chunk> future = craftWorld.getChunkAtAsync(X, Z, true);
            try {
                CraftChunk chunk = (CraftChunk) future.get();
                return chunk.getHandle();
            } catch (Throwable e) {
                e.printStackTrace();
            }
        }
        // TODO optimize
        return TaskManager.IMP.sync(() -> nmsWorld.getChunkAt(X, Z));
    }

[MiniDigger]

@dordsor21 am I reading this correctly, you are calling getChunkAsync asynchronous? That's bad.

[aikar]

closing as it's fawe issue

[dordsor21]

That's what the code was before I had anything to do with it. I figure whoever put it there thought "getChunkAtAsync" could be called "async"hronously which would make sense. Now I see that you cannot get a chunk async asynchronously apparently, and a chunk must be obtained asynchronously synchronously.

Also, if this cannot be called async, there really ought to be an async catcher on it, much as the normal getChunkAt method, or some mentioned of it in comments. Further also, the code itself actually attempts to handle called to getChunkAtAsync asynchronously. So if calling it asynchronously causes issues, then this probably is a paper issue as well.

[dordsor21]

I've now received the following crash. This was caused by a large operation (500x500) NOT with FAWE. It was done using PaperLib#getChunkAtAsync().thenAccept(Runnable) from the Main thread, and then setting each block in the chunk for each of the chunks. Chunk operations were kept at an average of 65ms (though because of Minecraft being Minecraft the TPS dropped to ~8). After completion, the server took a giant turd off the top of a building and froze up when I flew around slowly, eventually locking and throwing the below.

https://pastebin.com/raw/ZAVp9Pci

See: https://github.com/IntellectualSites/PlotSquared/blob/v5/Core/src/main/java/com/plotsquared/core/queue/GlobalBlockQueue.java#L114 for the queuing of tasks (Main thread)

See: https://github.com/IntellectualSites/PlotSquared/blob/v5/Core/src/main/java/com/plotsquared/core/queue/GlobalBlockQueue.java#L57 for the execution of tasks (Main thread)

See: https://github.com/IntellectualSites/PlotSquared/blob/v5/Bukkit/src/main/java/com/plotsquared/bukkit/queue/BukkitLocalQueue.java#L122 for chunk loading and setting of blocks. (Main thread)

Also to be noted: as of 614a664 when the above is completing, the server is practically deadlocked. Nothing can be done otherwise. The priorities are too OP and prevent almost anything happening on the main thread not directly related to a chunk load or a Runnable associated therewith. The ultimate crash is still the same. https://pastebin.com/raw/ss9f9z2W

[electronicboy]

This was caused by a large operation (500x500) NOT with FAWE

That's an entirely separate issue, see #3395 (and probably other reports..)

[dordsor21]

It's caused by exactly the same thing as the initial bug report, the same place of the same classpath. The linked issue bears some relation but is not the same. I do not think the initial issue here was caused by FAWE and was just a symptom of FAWE loading a lot of chunks.