Solved Server just stops processing the world randomly (no errors shown anywhere)

  • The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord

flaks314

New Member
Jul 29, 2019
3
0
0
I've been playing FTB mindcrack with a friend for a couple days now, I'm just hosting the server in the background on my desktop computer whenever either of us wants to play. It ran.. okish for the first few days, I had to restart it a couple times to get computercraft things running again, it seems to have trouble with filesystem access. Also, since about a day, computercraft's notion of a second seems to have increased to 1.2-2 seconds, while everything else kept running smoothly (i.e. TPS is still nicely at 20 and everything, CC just isn't synchronized properly).

While all that may or may not be related somehow, it's not my main problem at the moment. My problem right now is that the server hangs around five to ten minutes after starting it now. The thing I'm struggling with is that it's not displaying any kind of error or log message when it does. So my main question is whether there's some kind of debug or verbose mode which I can use to get more information about what it's doing when it crashes. But of course, more specific help would also be nice, so have a crash report. I've tried to make it as detailed as I can without any real leads...

What happens:
- At first, the server only stops processing world ticks. Clients can actually stay logged in for a while, and chat actually still works. Just everything else (including slash commands) doesn't. Threads still says [no.players] + [no.players].
- Eventually clients get disconnected with the usual "java.net.SocketTimeoutException: Read time out", and "Threads" switches to 0 + 0. However, the Players box is not cleared.
- Server GUI remains responsive and performance graph keeps shifting just fine. However, avg tick stops changing and the performance graph becomes a nice little rectangle, and the server does not respond to commands (i.e. /stop) in the GUI or in the console.
- The instance of java which is running the server keeps using approximately 100% CPU on a single core.

Here's the log for one of the crashing sessions: http://pastebin.com/raw.php?i=qQHqpav6.

In that particular session it crashed quite a bit before the Stopping server message by the way, I think that got written when I ctrl+c'd it in the console. It didn't actually exit though, I had to kill java.exe with task manager, but apparently logging still works after the crash... It just doesn't have anything to say for itself, I guess.

When does it happen:
I don't know, unfortunately. At first I thought there might be a corrupted chunk or something, but it doesn't seem to matter which direction I walk in.

It *doesn't* seem to happen when no one's logged in to the server, at least not within about half an hour.

The only notable things in our world that I can think of which are going on without player interaction is that there's a quarry running which is dumping items into an ender chest to our chunkloaded base (using the loader from ChickenChunks), where it's being sorted using a computer and an interactive sorter. Ore processing is done using ThermalExpansion. The computer/interactive sorter is not the problem though I don't think, as deleting the startup programs doesn't stop it crashing (see below).

What I've tried already:
- Deleted the contents of world/computer to shut off any computercraft programs, did nothing.
- /save-off, that actually *seemed* to help but given the random nature of the hang I can't be 100% sure of this. Also, I ran /save-all a couple times while in different places in the world, and that never once triggered the crash.
- Updated java, I was using 1.7.0_5 before. From a JDK I think, not sure (I'm also a java developer, just not for minecraft, not since MC beta 1.7.3 or so anyway). Anyway, it didn't fix it.
- Running with -Xms4G -Xmx4G. No effect, server crashed at 95% free, too.

General specs and stuff, for what it's worth:
- Modpack: Mindcrack, with no additional/removed mods
- Version: I would love to tell you but I don't know where to find it... In the client launcher it says recommended build, but no actual version number either. Or well, I'm probably just blind, so sorry in advance if I am...
- OS: Win7 pro x64, SP1
- Java: just updated; 1.7.0_17 (64 bit)
- Memory command line params: -Xms1G -Xmx2G (I just doubled the default values in the bat file since I have plenty of RAM)
- Hardware: FTB running on an SSD with 109GB free space, PC has 16GB RAM in quad channel on a high end i7 processor. It's not exactly underspec'd.

EDIT: Found the problem, it's a thread synchronization/deadlock bug in computercraft. Scroll down for details. I don't have a fix other than disabling wireless modems or computercraft altogether though, unfortunately.
 

CrazylikE

New Member
Jul 29, 2019
55
0
0
This sounds exactly like what is going on with my creeperhost server running Mindcrack 8.20 on MCPC with Prism and ForgeEssentials. I have been googling my a$$ off the last week, but have yet to find a fix for this, and its an issue that is going back several years by the looks of it. Hope you get it sorted, and that I can learn from it and fix mine too :/

Btw, I can add that we have quarry's, nukes and turtles disabled on our server and it still happens.
 

flaks314

New Member
Jul 29, 2019
3
0
0
Computercraft rednet deadlock?

Take a look at this thread for more info:
http://forum.feed-the-beast.com/threads/server-crash-freez-every-40-minutes.16181/

Thanks, but it seems unlikely, since I've tested without all the computercraft programs already. I'll look into it though, i.e., I'll spam random items to my sorting system for a while, and if that crashes it try again with modem ranges at 0.

Also, I'm running the server with java virtual machine debugger now to see if I can get a stack trace that way. It hasn't crashed yet now though... Murphy's law. Will post or edit the first post if I find anything.
 

flaks314

New Member
Jul 29, 2019
3
0
0
Hm, well... Turns out you were right. The debugger threw a nice red "Deadlock detected!" in my face, with the following stack traces for the deadlocked threads. So a turtle and a modem indeed.
Code:
"Server thread" prio=6 tid=0x000000001a578000 nid=0x174c waiting for monitor entry [0x000000002128e000]
  java.lang.Thread.State: BLOCKED (on object monitor)
    at dan200.computer.shared.WirelessModemPeripheral.pollChanged(WirelessModemPeripheral.java:90)
    - waiting to lock <0x00000007057550e8> (a dan200.turtle.shared.TurtleModem$Peripheral)
    at dan200.turtle.shared.TurtleModem$Peripheral.update(TurtleModem.java:72)
    at dan200.computer.core.apis.PeripheralAPI$PeripheralWrapper.update(PeripheralAPI.java:105)
    at dan200.computer.core.apis.PeripheralAPI.advance(PeripheralAPI.java:354)
    - locked <0x0000000705755090> (a [Ldan200.computer.core.apis.PeripheralAPI$PeripheralWrapper;)
    at dan200.computer.core.Computer.advance(Computer.java:560)
    - locked <0x0000000705754ff0> (a java.util.ArrayList)
    - locked <0x0000000705754f80> (a dan200.computer.core.Computer)
    at dan200.computer.shared.NetworkedComputerHelper.update(NetworkedComputerHelper.java:111)
    at dan200.turtle.shared.TileEntityTurtle.g(TileEntityTurtle.java:2350)
    at yc.h(World.java:2153)
    at in.h(WorldServer.java:516)
    at net.minecraft.server.MinecraftServer.r(MinecraftServer.java:680)
    at ho.r(DedicatedServer.java:269)
    at net.minecraft.server.MinecraftServer.q(MinecraftServer.java:599)
    at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:497)
    at fy.run(SourceFile:849)
 
  Locked ownable synchronizers:
    - None
 
"Coroutine-23" prio=6 tid=0x000000001afa6000 nid=0x14c8 waiting for monitor entry [0x00000000255bd000]
  java.lang.Thread.State: BLOCKED (on object monitor)
    at dan200.computer.core.Computer.queueLuaEvent(Computer.java:1064)
    - waiting to lock <0x0000000705754f80> (a dan200.computer.core.Computer)
    at dan200.computer.core.Computer.access$300(Computer.java:31)
    at dan200.computer.core.Computer$APIEnvironment.queueEvent(Computer.java:91)
    at dan200.computer.core.apis.PeripheralAPI$PeripheralWrapper.queueEvent(PeripheralAPI.java:220)
    - locked <0x00000007057550b8> (a dan200.computer.core.apis.PeripheralAPI$PeripheralWrapper)
    at dan200.computer.shared.WirelessModemPeripheral.receive(WirelessModemPeripheral.java:138)
    - locked <0x00000007057550e8> (a dan200.turtle.shared.TurtleModem$Peripheral)
    at dan200.computer.shared.WirelessModemPeripheral$SingleChannelReceiver.receive(WirelessModemPeripheral.java:50)
    at dan200.computer.shared.WirelessNetwork.tryTransmit(WirelessNetwork.java:87)
    at dan200.computer.shared.WirelessNetwork.transmit(WirelessNetwork.java:75)
    - locked <0x0000000706d6eea8> (a dan200.computer.shared.WirelessNetwork)
    at dan200.computer.shared.WirelessModemPeripheral.callMethod(WirelessModemPeripheral.java:269)
    - locked <0x0000000705757728> (a dan200.computer.shared.TileEntityWirelessModem$Peripheral)
    at dan200.computer.shared.TileEntityWirelessModem.callMethod(TileEntityWirelessModem.java:117)
    at dan200.computer.core.apis.PeripheralAPI$PeripheralWrapper.call(PeripheralAPI.java:116)
    - locked <0x0000000706d3ca30> (a dan200.computer.core.apis.PeripheralAPI$PeripheralWrapper)
    at dan200.computer.core.apis.PeripheralAPI.callMethod(PeripheralAPI.java:464)
    at dan200.computer.core.LuaJLuaMachine$2.invoke(LuaJLuaMachine.java:304)
    - locked <0x0000000706fb8978> (a dan200.computer.core.LuaJLuaMachine$2)
    at org.luaj.vm2.LuaClosure.execute(Unknown Source)
    at org.luaj.vm2.LuaClosure.call(Unknown Source)
    at org.luaj.vm2.LuaClosure.execute(Unknown Source)
    at org.luaj.vm2.LuaClosure.onInvoke(Unknown Source)
    at org.luaj.vm2.LuaClosure.invoke(Unknown Source)
    at org.luaj.vm2.LuaClosure.execute(Unknown Source)
    at org.luaj.vm2.LuaClosure.onInvoke(Unknown Source)
    at org.luaj.vm2.LuaClosure.invoke(Unknown Source)
    at org.luaj.vm2.lib.BaseLib.pcall(Unknown Source)
    at org.luaj.vm2.lib.BaseLib$BaseLibV.invoke(Unknown Source)
    at org.luaj.vm2.LuaClosure.execute(Unknown Source)
    at org.luaj.vm2.LuaClosure.onInvoke(Unknown Source)
    at org.luaj.vm2.LuaClosure.invoke(Unknown Source)
    at org.luaj.vm2.LuaClosure.execute(Unknown Source)
    at org.luaj.vm2.LuaClosure.onInvoke(Unknown Source)
    at org.luaj.vm2.TailcallVarargs.eval(Unknown Source)
    at org.luaj.vm2.TailcallVarargs.arg1(Unknown Source)
    at org.luaj.vm2.LuaClosure.call(Unknown Source)
    at org.luaj.vm2.LuaClosure.execute(Unknown Source)
    at org.luaj.vm2.LuaClosure.onInvoke(Unknown Source)
    at org.luaj.vm2.LuaClosure.invoke(Unknown Source)
    at org.luaj.vm2.LuaClosure.execute(Unknown Source)
    at org.luaj.vm2.LuaClosure.onInvoke(Unknown Source)
    at org.luaj.vm2.LuaClosure.invoke(Unknown Source)
    at org.luaj.vm2.lib.BaseLib.pcall(Unknown Source)
    at org.luaj.vm2.lib.BaseLib$BaseLibV.invoke(Unknown Source)
    at org.luaj.vm2.LuaClosure.execute(Unknown Source)
    at org.luaj.vm2.LuaClosure.call(Unknown Source)
    at org.luaj.vm2.LuaClosure.execute(Unknown Source)
    at org.luaj.vm2.LuaClosure.onInvoke(Unknown Source)
    at org.luaj.vm2.LuaClosure.invoke(Unknown Source)
    at org.luaj.vm2.LuaThread$State.run(Unknown Source)
    - locked <0x0000000706fbf418> (a org.luaj.vm2.LuaThread$State)
    at java.lang.Thread.run(Unknown Source)
 
  Locked ownable synchronizers:
    - None

I really don't know how it managed to crash without the startup code for all the computers though. Maybe I just messed up getting rid of them temporarily or something. This is really disappointing for me though, my entire automation setup is based on computercraft... Anyways, it's not really an FTB issue then, but a CC one, so I'll mark it as solved here in a minute.

The way I managed to get this information is:
- Download a recent JDK from Oracle if you don't have one yet and install it, currently it's at http://www.oracle.com/technetwork/java/javase/downloads/index.html. If the link breaks, google is your friend.
- Add -Xdebug to the command line parameters which start the serverand start it, e.g. run java -Xms4G -Xmx4G -Xdebug -jar ftbserver.jar. You need to do this for java debug interface programs to be allowed to attach to it. Note/edit: I think this flag lags the server significantly over time, so remove the flag when you're done.
- Run [JDK install dir]/bin/jvisualvm.exe
- Mount it to ftbserver.jar, it should be in the list on the left, double click it.
- Go to the threads tab. You can get a stack trace from all the threads using the thread dump button. It should automatically scan for deadlocks while it's running.
This is probably not going to help you if you don't know approximately what you're looking for in java stack traces and stuff though.
 

Naolas

New Member
Jul 29, 2019
190
0
0
Thanks for the detailed info. :)

One workaround atm seems to be to only use computers, which seem to work better than turtles. The CC devs have also acknowledged the bug and are working on a fix. So fingers crossed they can find this nasty bug soon.