AtomicStryker's Battle Towers

AtomicStryker's Battle Towers

23M Downloads

[1.14.4] Server hard lock on - atomicstryker.ruins.common.RuinsMod.onEntityEnteringChunk()100.00%31700ms

ProsperCraft opened this issue · 14 comments

commented

Here is a warmroast of the server hard locked for 5 minutes. I killed the process after the profile.

4c0df3bfe8415b90baeb8630e450ca49

1.14.4 Modpack - https://www.curseforge.com/minecraft/modpacks/the-adventures-of-halk

forge-1.14.4-28.1.40
ruins-1.14.4.2

commented

The server hard locks, and when I run the warmroast profile this is the state it is in.

Would it help to have our scripts? They are available in the modpack download or I can provide them.

commented

Well crud, I thought I had it narrowed down, but it just locked and doesn't list ruins this time.

50f4553b378bbe70ebcfe162ba653e26

commented

During world generation, any invocation on the raw World object that causes a call to World#getChunk will deadlock. This event can, unfortunately, fire during worldgen, which means you need to somehow check for main thread before accessing chunks

commented

Here is the next one.

2c0551483649fc52ff242820eb19f127

commented

During world generation, any invocation on the raw World object that causes a call to World#getChunk will deadlock.

What?! That can't be. MC is permanently generating chunks in the background as players move around, if it was as WILDLY unsafe as you claim the game would deadlock itself constantly. And i would expect there to be some kind of safety layer in IWorldReader preventing exactly that.

If you could provide some of the template files maybe, i could fly around on my system in creative and see if it happens.

commented
commented

In 1.14 mojang moved to an async chunk generation system. This involves starting up another thread to generate every chunk that is requested. During that phase, the chunk is isolated and any access to that chunk MUST be done from the IWorld of the chunk.

Re-accessing that chunk from the main thread has no effect, it simply notices that the chunk is being generated and waits.

The problem comes when something attempts to access that chunk, from another thread (like a chunk worker thread), from the main world object, instead of the isolated IWorld that the chunk uses to generates. Now this is a really big problem with entities, since the entities cannot use the IWorld and must use the World of the chunk.

That series of events leads us to where using the World of any Entity while in a chunk gen thread, and accessing the chunk that the entity is in, will deadlock.

commented

here is the new one.

2b94f17b63a03c920bb23c190ea2bb14

commented

Do you mind if i put your templates as new "defaults"? Just so people will stop PMing me "durr nothing spawns".

I have a version here in which i've flown around aggressively for a couple of minutes and it didn't deadlock. It basically aborts template spawning if it finds it left generated chunk space.

commented

Yes, we don't mind, go ahead.

As the next troubleshooting step, I disabled Ruins serverside, and waiting to see if we get another deadlock, nothing yet.

commented

Alright then!
588e0c1
This should hopefully fix your issues.

That series of events leads us to where using the World of any Entity while in a chunk gen thread, and accessing the chunk that the entity is in, will deadlock.

Thank you kindly for your explanation of the problem. I was not aware of this mechanic.

commented

Pushed it to curse aswell

commented

Hard locked up again -

5c1619c4edd9cb93c6b925402355fc04

commented

It would appear the server dead-locks on block interaction. The first is a call to removeBlock, the second getBlockState. These are concurrently executed calls... Is the server locked up by this?