Crash on startup
idnthvn opened this issue · 7 comments
For feature requests, just erase this template and clearly describe the feature you'd like to see
Minecraft Version 1.12.2
Forge Version 1.12.2 - 2847
Mod Version tried 383,380, and version 375
Describe your problem, including steps to reproduce it
run game, play for however many minutes. Than after a reboot, itll crash.
Any other comments?
at me.desht.pneumaticcraft.common.semiblock.SemiBlockManager.onServerTick(SemiBlockManager.java:208)
Thats the crash. here is my crash log
[crash-2020-02-12_13.16.35-server.txt]
i am using spongeforge as well, but it is pretty random. I managed to get it to boot by deleting my config file from forge and spongeforge once before, but than after a reboot, it crashed again
edit: I should mention the server completely starts and loads and runs for a few seconds. even to a point where i felt like logging on, an soon as i connect, it throws the error as well.
spongeforge version 1.12.2-2838-7.1.70-RC3994
I rebooted server without spongeforge. worked. I downgraded to spongeforge 1.12.2-2838-7.19-RC3989 (recommended) and have a launched server. Will comment if it crashes after a reboot
Hmm, it feels like Spongeforge is possibly doing something off-thread. I've been over the SemiBlockManager code, and I'm pretty sure it's not doing any modification of the hashmap while iterating. So the only other possibility is cross-thread modification.
I'll keep this open for now, but I'm not sure there's much I can do about it...
Update: Did not fix it.
So far the only way to make the server launch so far after twice it has crashed with this is to completely start server without spongeforge (btw it crashes still without sponge) let it do a world save, than re install sponge forge (new or old) and it boots.
Than on reboot, the crash comes back.
So to give some clarity, Sponge does a lot of sanity checks on threadedness to accessors for things like world modifications, events, and a few other cases, but the only thing I know that we're turning into a possible asynchronous function is for block lighting updates. I gave a brief review of the SemiBlockManager code itself and I can't find any obvious areas where that'd be affected, but @desht you know the code better than I 😄, so maybe the conversation can be had where a possible change is reflexively adding your own thread checks to the semiBlock map access points, because I can assure you that the thread of the server tick event is still going to be the main server thread, but I don't know about the multiple other places that semiBlock is being accessed.
The problem I'd imagine is likely more fine-grained to the map being accessed/read possibly even from chunk saving (since in forge, chunk saving can occur off thread) which would likely make sense if the server is crashing on startup since there's some additional chunk load/unload events being thrown.
Thanks for the update. Yeah, a bit more thread checking is probably the way to go. I know chunk loading/unloading happens off-thread, but I can't remember offhand if Forge posts the events asynchronously or not (don't have a 1.12.2 environment to hand to check this right now).
I think my setup rules out the sponge async lighting being the cause here, As i have that function disabled, my server would crash shortly after startup (3-5m).
I've done some more investigation, and:
- There's no access happening off-thread that I can see
- I can't load spongeforge in my dev environment (exits pretty fast with a whole load obfuscated symbols not found)... which means I have no possibility of reproducing the problem in my IDE
So, sorry... I'm out of ideas. If it's any consolation, this won't be an issue in 1.14.4+ since I've completely written semiblocks to be entities, but it's not feasible to backport that rewrite to 1.12 at this point.