search

WearBlackAllDay / DimensionalThreading

An attempt to optimize the fabric server, by assigning each dimension their own thread.
MIT License
255 stars 22 forks source link

Server crashing after installing DimThread. #29

Open Greg-J opened 3 years ago

Greg-J commented 3 years ago

All very similar crash reports. The report from the user that was logged on said it started happening the moment she went into the nether.

crash-2021-06-11_23.51.03-server.txt crash-2021-06-12_02.10.06-server.txt crash-2021-06-12_02.13.26-server.txt crash-2021-06-12_02.16.37-server.txt crash-2021-06-12_02.22.41-server.txt crash-2021-06-12_02.27.16-server.txt

A list of mods the server is running:

  1. carpet-extra-1.17-1.4.40.jar
  2. DimThread-1.2.4.jar
  3. fabric-api-0.35.0+1.17.jar
  4. fabric-carpet-1.17-1.4.40+v210608.jar
  5. Fabric-Discord-Link-0.9.4.jar
  6. krypton-0.1.3.jar
  7. lithium-fabric-mc1.17-0.7.0.jar
  8. mostructures-1.2.0-pre2+mc.1.17.jar
  9. worldedit-fabric-mc1.17-7.2.6-SNAPSHOT-dist.jar

Noteworthy: We are running a number of datapacks. Most noteable that I could thing could potentially cause compatibility issue would be the CavesAndCliffsPreview.zip datapack, and Incendium_v3.2.zip.

WearBlackAllDay commented 3 years ago

(admittely only read the first one) basically the same i said in #28 applies, tho your crash seems to be identical. The common mods in this case are lithium and fdlink, so you probably wanna test out those 2. My guess would be lithium, but a confimation would be nice.

@pooky125 Im leaving this one open for as a common issue for a potential lithium incompatibility.

pooky125 commented 3 years ago

Ok, so, I tested the lastest version again on my server. Once without fdlink, and once without lithium. In both cases, the server still crashed. I've included the crash logs.

crash-2021-06-15_00.52.41-server.txt crash-2021-06-15_00.51.29-server.txt

As an additional note, I'm not running the CavesAndCliffsPreview pack from Mojang.

WearBlackAllDay commented 3 years ago

The first one is without lithium indeed, fdlink however is present on both crashes. I went on and tested ldimthread + lithium on my own server, without any crashes. It seems like it is fdlink causing the issue then, i will look into that later.

pooky125 commented 3 years ago

OK, so, I did some additional testing. Figured if it was the chat bot that was the problem, I could replace it with a different chat bot, see if I could get a different response. New chat mod was installed, but not configured or connected to anything yet, and the server crashed so hard, it wouldn't reboot the second time. Once I deleted Dimensional Threading, it started right back up. Here are todays crash logs. crash-2021-06-16_18.15.57-server.txt crash-2021-06-16_18.15.31-server.txt

The new discord link mod I've installed, is disfabric.

Greg-J commented 3 years ago

@pooky125, have you tested without any chatbot yet to see if it is stable without it?

pooky125 commented 3 years ago

Yes. It actually crashed even faster than usual. Usually I get about 2 minutes from launch to crash. This time, I had about 15 seconds. crash-2021-06-16_20.03.31-server.txt

Greg-J commented 3 years ago

Yes. It actually crashed even faster than usual. Usually I get about 2 minutes from launch to crash. This time, I had about 15 seconds. crash-2021-06-16_20.03.31-server.txt

Are you in the overworld when it happens, or in the Nether/End?

pooky125 commented 3 years ago

I was in the overworld.

Mincraftr commented 3 years ago

This doesn't seem to be an issue with other mods, I had it occur both with a bunch of mods and datapacks as well as with only FabricAPI, DimThread and the Incendium datapack. This seems to be an issue between DimThread and datapack functions. For my tests with only FabricAPI, DimThread and Incendium, I would create a world with the Incendium datapack but with load.json and tick.json removed from the zip (data\minecraft\tags\functions), go to the nether and have no crashes while flying around for a while, reloading the world and then flying around more. Adding back load.json and tick.json and loading up the world would result in a crash usually fairly quickly.

KaptainWutax commented 3 years ago

I can confirm it's a compatibility issue with incendium, although I still managed to reproduce it 3 times with an empty load and tick. It seems to happen consistently after loading a forbidden castle piglin thingy.

Mincraftr commented 3 years ago

I can confirm it's a compatibility issue with incendium, although I still managed to reproduce it 3 times with an empty load and tick. It seems to happen consistently after loading a forbidden castle piglin thingy.

I don't believe it's specific to Incendium, as pooky125 does not seem to have been using it even in their earliest crash report, as well as them having the issue in a dimension other than the nether, Incendium just seems to be the most consistent for testing. You also don't seem to be able to just remove/empty load & tick afterwards as the issue will still occur, the world instead has to be (re)created without them for the issue to not occur.

pooky125 commented 3 years ago

I can confirm it's a compatibility issue with incendium, although I still managed to reproduce it 3 times with an empty load and tick. It seems to happen consistently after loading a forbidden castle piglin thingy.

I don't believe it's specific to Incendium, as pooky125 does not seem to have been using it even in their earliest crash report, as well as them having the issue in a dimension other than the nether, Incendium just seems to be the most consistent for testing. You also don't seem to be able to just remove/empty load & tick afterwards as the issue will still occur, the world instead has to be (re)created without them for the issue to not occur.

Correct, I'm not using Incendium. I had to google it to figure out what you all were even talking about. BUT, I do have several datapacks with a tick.json and load.json. That would definitely link it all together.