Client-Server (singleplayer) race condition crash on startup
Vectrobe opened this issue ยท 7 comments
Issue description
This seems to be rare but I'm just going to report it anyway in case something more pops up
crash-2025-03-27_17.10.22-server.txt
Steps to reproduce
unknown, launch mekanism on a test flatworld, seems to have a 10% chance of occurring
Minecraft version
1.21.1 (Latest)
NeoForge version
21.1.133
Mekanism version
10.7.13 (Latest)
Other relevant versions
refer to crash log
If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)
No response
That looks like something went wrong during startup, but was swallowed and then later failed with the earlier stacktrace.
Something is wrong with your environment (incomplete or corrupted mod download) or someone is starting a worker thread with a wrong configuration...
It's one of those "shouldn't happen" kinda bugs, and certainly not being rare. You don't happen to have one of those fried Intel processors do you?
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.IllegalStateException: No valid ServiceImpl for ISecurityUtils found [in thread "Worker-Main-4"]
at TRANSFORMER/[email protected]/mekanism.api.security.ISecurityUtils.lambda$static$0(ISecurityUtils.java:27) ~[Mekanism-1.21.1-10.7.13.78.jar%23386!/:10.7.13] {re:classloading}
at java.base/java.util.Optional.orElseThrow(Optional.java:403) ~[?:?] {re:mixin}
at TRANSFORMER/[email protected]/mekanism.api.security.ISecurityUtils.<clinit>(ISecurityUtils.java:27) ~[Mekanism-1.21.1-10.7.13.78.jar%23386!/:10.7.13] {re:classloading}
at TRANSFORMER/[email protected]/mekanism.common.lib.security.SecurityUtils.get(SecurityUtils.java:31) ~[Mekanism-1.21.1-10.7.13.78.jar%23386!/:10.7.13] {re:classloading}
at TRANSFORMER/[email protected]/mekanism.common.lib.security.ItemSecurityUtils.addSecurityTooltip(ItemSecurityUtils.java:65) ~[Mekanism-1.21.1-10.7.13.78.jar%23386!/:10.7.13] {re:classloading}
at TRANSFORMER/[email protected]/mekanism.common.item.ItemRobit.appendHoverText(ItemRobit.java:71) ~[Mekanism-1.21.1-10.7.13.78.jar%23386!/:10.7.13] {re:classloading}
at TRANSFORMER/[email protected]/net.minecraft.world.item.ItemStack.getTooltipLines(ItemStack.java:770) ~[client-1.21.1-20240808.144430-srg.jar%23306!/:?] {re:mixin,pl:accesstransformer:B,re:computing_frames,pl:accesstransformer:B,re:classloading,pl:accesstransformer:B,pl:mixin:APP:emi.mixins.json:ItemStackMixin from mod emi,pl:mixin:APP:geckolib.mixins.json:common.ItemStackMixin from mod geckolib,pl:mixin:APP:clean_tooltips-common.mixins.json:ItemStackMixin from mod clean_tooltips,pl:mixin:APP:clean_tooltips-neoforge.mixins.json:ItemStackMixin from mod clean_tooltips,pl:mixin:APP:cucumber.mixins.json:ItemStackMixin from mod cucumber,pl:mixin:APP:glitchcore.mixins.json:MixinItemStack from mod glitchcore,pl:mixin:A}
at TRANSFORMER/[email protected]/net.minecraft.client.multiplayer.SessionSearchTrees.lambda$getTooltipLines$0(SessionSearchTrees.java:51) ~[client-1.21.1-20240808.144430-srg.jar%23306!/:?] {re:mixin,pl:accesstransformer:B,pl:runtimedistcleaner:A,re:classloading,pl:accesstransformer:B,pl:mixin:APP:jade.mixins.json:SessionSearchTreesMixin from mod jade,pl:mixin:A,pl:runtimedistcleaner:A}
at java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:273) ~[?:?] {}
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) ~[?:?] {}
at java.base/java.util.Collections$2.tryAdvance(Collections.java:5073) ~[?:?] {}
at java.base/java.util.Collections$2.forEachRemaining(Collections.java:5081) ~[?:?] {}
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) ~[?:?] {}
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[?:?] {}
at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) ~[?:?] {}
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) ~[?:?] {}
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?] {}
at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) ~[?:?] {}
at TRANSFORMER/[email protected]/net.minecraft.client.searchtree.SearchTree.plainText(SearchTree.java:21) ~[client-1.21.1-20240808.144430-srg.jar%23306!/:?] {re:classloading}
at TRANSFORMER/[email protected]/net.minecraft.client.searchtree.FullTextSearchTree.<init>(FullTextSearchTree.java:16) ~[client-1.21.1-20240808.144430-srg.jar%23306!/:?] {re:classloading}
at TRANSFORMER/[email protected]/net.minecraft.client.multiplayer.SessionSearchTrees.lambda$updateRecipes$7(SessionSearchTrees.java:66) ~[client-1.21.1-20240808.144430-srg.jar%23306!/:?] {re:mixin,pl:accesstransformer:B,pl:runtimedistcleaner:A,re:classloading,pl:accesstransformer:B,pl:mixin:APP:jade.mixins.json:SessionSearchTreesMixin from mod jade,pl:mixin:A,pl:runtimedistcleaner:A}
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768) ~[?:?] {}
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760) ~[?:?] {}
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387) ~[?:?] {}
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312) ~[?:?] {}
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843) ~[?:?] {re:computing_frames}
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808) ~[?:?] {re:computing_frames}
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188) ~[?:?] {}
crash logs do contain processor info, its a particular race condition that was probably introduced with the mekanism and neoforge update to .133, which was mentioned in another issue.
as for what and why it occurs isnt exactly clear, and important exceptions during the client loading should trigger a client crash then, as opposed to during world-server startup, which is to say that in this crash the server context initiated the crash when one of the threads tried to access mekanism.api before the server context had initiated the api class, mekanism.common had been loaded in and was already used by one of the threads when mekanism.common tried to access mekanism.api
when one of the threads tried to access mekanism.api before the server context had initiated the api class
That's not how that works, nor is it happening on the server thread
Same problem here. Happens after loading into a world and then breaking a block. No other action has caused a crash yet.
when one of the threads tried to access mekanism.api before the server context had initiated the api class
That's not how that works, nor is it happening on the server thread
if its not happening in the server context why is it the server context that crashes...?
My bad, the end result is it crashing on the server thread, but the error reported as caused by seems to have been cached from something earlier in start up or reload, by calling things wrong
Like I said, you got some weird things happening. The debug log may help
closing in favor of #8393 as no log supplied