FastCraft

FastCraft

138k Downloads

server lock on shutdown (preventing shut down)

PhanaticD opened this issue ยท 11 comments

commented

Description

server cannot be shut down

Reproduction

stop server

Output/Files

        - locked <0x00000003cf161c38> (a org.bukkit.plugin.SimplePluginManager)
        at org.bukkit.craftbukkit.v1_12_R1.event.CraftEventFactory.handleInventoryCloseEvent(CraftEventFactory.java:923)
        at net.minecraft.server.v1_12_R1.EntityPlayer.closeInventory(EntityPlayer.java:962)
        at org.bukkit.craftbukkit.v1_12_R1.entity.CraftHumanEntity.closeInventory(CraftHumanEntity.java:401)
        at co.kepler.fastcraftplus.api.gui.GUI.dispose(GUI.java:107)
        at co.kepler.fastcraftplus.api.gui.GUI.disposeAll(GUI.java:62)
        at co.kepler.fastcraftplus.FastCraftPlus.unload(FastCraftPlus.java:91)
        at co.kepler.fastcraftplus.FastCraftPlus.onDisable(FastCraftPlus.java:76)
        at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:266)
        at org.bukkit.plugin.java.JavaPluginLoader.disablePlugin(JavaPluginLoader.java:344)
        at org.bukkit.plugin.SimplePluginManager.disablePlugin(SimplePluginManager.java:424)
        at org.bukkit.plugin.SimplePluginManager.disablePlugins(SimplePluginManager.java:417)
        at org.bukkit.craftbukkit.v1_12_R1.CraftServer.disablePlugins(CraftServer.java:344)
        at net.minecraft.server.v1_12_R1.MinecraftServer.stop(MinecraftServer.java:485)
        at net.minecraft.server.v1_12_R1.MinecraftServer.run(MinecraftServer.java:700)
        at java.lang.Thread.run(Thread.java:748)

Server Details

  • FastCraft Version: 0.27.2
  • Server Version: git-Paper-1168 (MC: 1.12) (API version 1.12-R0.1-SNAPSHOT)
commented

Erroring line of code: https://github.com/BenWoodworth/FastCraft/blob/FastCraftv0/src/main/java/co/kepler/fastcraftplus/api/gui/GUI.java#L107

I'll test around with Paper Spigot and see if I can reproduce this.

Basically, the server is stopping, FastCraft is being disabled, FastCraft is closing the GUI inventories. FastCraft is closing the GUI's when it's unloaded, because reloading the server with /reload will leave the GUI inventories open, and FastCraft can't manage the inventory anymore, so players would be able to take items from the GUI.

commented

maybe instead of a while loop, just get the viewers, then loop through those

because i can see how that might get stuck

commented

I don't think /reload is causing this issue, it's just the reason the code is the way it is.

And I'm using a while loop instead of a for loop is because a for loop would cause a ConcurrentModificationException. Java doesn't like when you modify a list while you iterate through it.

I'm starting to play around with Paper Spigot. I'll keep you updated if I figure out anything.

commented

make a copy of it :P

commented

I just tried stopping a Paper server in a few different scenarios:

  • Open GUI
  • Open GUI, then click on crafting table to show crafting grid
  • Open GUI, then close it

I wasn't able to cause the error that you were getting.

Have you been able to figure out what might be causing the server lock bug? I still haven't been able to make the bug happen.

commented

no, I had to remove it from my servers, all I have it what I provided originally

commented

Okay. I'm going to close this issue, since it may be a bug with Paper Spigot, and since I'm unable to reproduce it. If you or someone else can help me reproduce it, I'll re-open the issue.

commented

I am going to try with using this code on my servers:

    private void dispose(boolean removeFromGuis) {
        List<HumanEntity> viewers = new ArrayList<>(inv.getViewers());
        for(HumanEntity e : viewers){
            e.closeInventory();
        }
        if (removeFromGuis) {
            guis.remove(this);
        }
    }
commented

Give it a shot! I don't think it'll make any difference, since it's calling closeInventory() on the players either way, and calling closeInventory() seems to be the issue.

Were there any lines in the stack trace before - locked...?

commented

havent gotten any more issues since making that change

commented

Unfortunately, since we haven't been able to reproduce the issue, I have no way of testing whether this was a one time bug, or whether your code change fixed it.

I likely won't be releasing another FastCraft v0.* build, so I would stick with the jar you built yourself for now. I'm rewriting FastCraft v1 from scratch, so hopefully this won't be an issue.

I decompiled Paper, and it looks like something is happening with the callEvent(event) line. That's the only call that uses
The stack trace says the thread was locked by a SimplePluginManager. The callEvent(event) line is the only function call that uses a SimplePluginManager, so I suspect something's going on with that.

CraftEventFactory:

public static void handleInventoryCloseEvent(EntityHuman human) {
  InventoryCloseEvent event = new InventoryCloseEvent(human.activeContainer.getBukkitView());
  human.world.getServer().getPluginManager().callEvent(event); // CraftEventFactory.java:923
  human.activeContainer.transferTo(human.defaultContainer, human.getBukkitEntity());
}

SimplePluginManager:

public void callEvent(Event event) {
  if (event.isAsynchronous()) {
    if (Thread.holdsLock(this)) {
      throw new IllegalStateException(event.getEventName() + " cannot be triggered asynchronously from inside synchronized code.");
    }
    if (this.server.isPrimaryThread()) {
      throw new IllegalStateException(event.getEventName() + " cannot be triggered asynchronously from primary server thread.");
    }
    fireEvent(event);
  } else {
    synchronized (this) {
      fireEvent(event);
    }
  }
}

fireEvent(event) is being called in a synchronized block, so that's probably why the server locked up. The loop you changed wouldn't block the thread, so something else (perhaps a Paper optimization, or an asynchronous method?) is causing the thread to block when the event is being fired.

You're the first person to report this in the few years this plugin has been released, so I suspect it has something to do with your server specifically, whether it be Paper, or another plugin making asynchronous calls, or a mix of the two. I'm going to leave this closed for now, unless you're able to consistently reproduce the issue.