GT-New-Horizons-Modpack
GT-New-Horizons-Modpack copied to clipboard
GTNewHorizons
Stocking input hatch turn off machine due to crash
Your GTNH Discord Username
lord_cocain
Your Pack Version
2.5.0
Your Server
personal server
Java Version
Java 20
Type of Server
Vanilla Forge
Your Expectation
working as stocking bus
The Reality
its turn of machine sometimes
Your Proposal
same intonation that may help? 99.9% sure that happen only in pull mode.
i have setup on compact that not fail: fluid come in subnet with two 1 type fluid cell, every recipe is one single step craft. if i reduce pattern size to force many steps its start failing.
Final Checklist
- [X] I have searched this issue tracker and there is nothing similar already. Posting on a closed issue saying the bug still exists will prompt us to investigate and reopen it once we confirm your report.
- [X] I can reproduce this problem consistently by follow the exact steps I described above, or this does not need reproducing, e.g. recipe loophole.
- [X] I have asked other people and they confirm they also have this problem by follow the exact steps I described above, or this does not need reproducing, e.g. recipe loophole.
potentially unrelated but worth noting:
[10:06:16] [Server thread/DEBUG] [FML/]: Gathering id map for writing to world save World
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: java.util.ConcurrentModificationException
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at java.base/java.util.HashMap$HashIterator.nextNode(HashMap.java:1605)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at java.base/java.util.HashMap$KeyIterator.next(HashMap.java:1628)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.NBTTagCompound.func_74734_a(NBTTagCompound.java:29)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.NBTTagCompound.func_150298_a(NBTTagCompound.java:376)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.NBTTagCompound.func_74734_a(NBTTagCompound.java:31)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.NBTTagCompound.func_150298_a(NBTTagCompound.java:376)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.NBTTagCompound.func_74734_a(NBTTagCompound.java:31)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.NBTTagCompound.func_150298_a(NBTTagCompound.java:376)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.NBTTagCompound.func_74734_a(NBTTagCompound.java:31)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.NBTTagList.func_74734_a(NBTTagList.java:32)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.NBTTagCompound.func_150298_a(NBTTagCompound.java:376)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.NBTTagCompound.func_74734_a(NBTTagCompound.java:31)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.NBTTagCompound.func_150298_a(NBTTagCompound.java:376)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.NBTTagCompound.func_74734_a(NBTTagCompound.java:31)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.CompressedStreamTools.func_150663_a(CompressedStreamTools.java:149)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.nbt.CompressedStreamTools.func_74800_a(CompressedStreamTools.java:139)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.world.chunk.storage.AnvilChunkLoader.func_75821_a(AnvilChunkLoader.java:265)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.world.chunk.storage.AnvilChunkLoader.func_75814_c(AnvilChunkLoader.java:251)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.world.storage.ThreadedFileIOBase.func_75736_b(SourceFile:30)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.world.storage.ThreadedFileIOBase.run(SourceFile:23)
[10:06:18] [File IO Thread/INFO] [STDERR/serverutilities]: [java.lang.Throwable$WrappedPrintStream:println:785]: at java.base/java.lang.Thread.run(Thread.java:1583)
[10:06:26] [Server thread/DEBUG] [FML/]: The world 2632d4ec (World) may have leaked: seen 745 times.
[07:47:41] [Server thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:785]: java.lang.NullPointerException: Cannot invoke "appeng.api.storage.data.IAEFluidStack.setStackSize(long)" because "request" is null
[07:47:41] [Server thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:785]: at gregtech.common.tileentities.machines.GT_MetaTileEntity_Hatch_Input_ME.endRecipeProcessing(GT_MetaTileEntity_Hatch_Input_ME.java:242)
[07:47:41] [Server thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:785]: at gregtech.api.metatileentity.implementations.GT_MetaTileEntity_MultiBlockBase.endRecipeProcessing(GT_MetaTileEntity_MultiBlockBase.java:1421)
[07:47:41] [Server thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:785]: at gregtech.api.metatileentity.implementations.GT_MetaTileEntity_MultiBlockBase.checkRecipe(GT_MetaTileEntity_MultiBlockBase.java:500)
[07:47:41] [Server thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:785]: at goodgenerator.blocks.tileEntity.base.LargeFusionComputer.onPostTick(LargeFusionComputer.java:318)
[07:47:41] [Server thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:785]: at gregtech.api.metatileentity.BaseMetaTileEntity.func_145845_h(BaseMetaTileEntity.java:547)
[07:47:41] [Server thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.world.World.func_72939_s(World.java:1939)
[07:47:41] [Server thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:1146)
[07:47:41] [Server thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:636)
[07:47:41] [Server thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:334)
[07:47:41] [Server thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:547)
[07:47:41] [Server thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:427)
[07:47:41] [Server thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:785]: at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:685)
This is the error
I think its happen because sometimes slot updating happen before end recipe check, storedFluids[i] already null and cant be checked, that explain why happen only in auto pull mode, also explain why you can get wrong positive check for "failed extract from storage" error. Also idk why, but sometimes its just cant happen on current game load, i need restart game and then it start happen.
Not really sure if this is the same bug, but I definitely get crashes with stocking hatches in my MEBF without using auto-pull (it's just the hatch).
It was working fine, but I added a crafting input buffer for meteoric steel and since then it's been acting up. The stocking hatch itself is definitely the problem, there's no stocking buses at all on my MEBF.
I added the fml-client-latest just in case that's relevant at all, I'm not sure if there's more info I can provide but you probably wanna @ me in discord (Fluorine Queen is my server nickname, has_problems is the actual discord username) since I don't find myself logged in to github very often. fml-client-latest.log
Is this issue fixed?
I believe it is crucial for 2.6.0 and (if not fixed) should be part of #15690 .
Advanced Stocking Input Bus is also affected by this bug ig. My Large Essentia Smeltery was often turned off due to similar crash until I turned back to normal ibus. 😞
Is the fluid being stocked pulled from a GT tank via a storage bus, by any chance? I had this happen but thus far only for stocked oxygen, which I have not yet migrated to a digital singularity. I also have EIO conduits pulling from the same tank, and the crash I saw said it couldn't pull the expected amount of fluid.
ME hatches/busses tend to break in awkward ways if their content is queried more than once per start/endRecipeProcessing() batch. e.g. AdvAssline used to dupe items because it'd query items more than once per batch. I ended up adding a cache as a bandaid fix, as I did not quite understand how ME hatch/bus work.
I wonder if this is somehow related.
Having similar issue on 2.6 beta. I input crafiting items into a subnet which distributes them via stocking hatches and buses to multiple AALs. My pico circuit, optical assembly and gallifreyan parts AALs started to crap itself. Did not happen when only using 1 AAL per recipe.
This error happens when big crafts are ending and it cannot start first slice. Crashes AAL and voids all crafts inside.
not fixed, just tested newest gt version on special test world and still getting error
Can you share your "special test world" in some form? we devs still have trouble replicating this issue
https://drive.google.com/file/d/1b2OjusnAHqdvmvRpPhZ7OboooeYLrXaR/view?usp=sharing Personal World 180, X: 54, Z: 23, Y: 133 Put in saves and then load mc. On coordinates quadruple wall shared Large Processing Factory, need just turn on them and wait, should broke pretty quick.
actually, I forget to upgrade to beta3 and I was still testing with beta2 (without the fix).
After upgrading to beta3, I left the machine you mentioned to run for ~10min (of course not 100% uptime. I just let your base continue doing whatever you have made it to do) and no crash so far.
EDIT: dropped a creative fluid cell filled with molten metal into the chest and I'm now off for bed. will see how it turns out
Forgot to say, but you need copy world from archive for every test. Looks like bug happen when many fluids switching, also maybe some fluids affect to it. Because i had it working for hours with many different fluids, but sometime it cant work even for minute.
Thanks. That's quite helpful indeed. I think I've found a new way how this could break. It looks like the internal state is not mutated in a consistent way, leading to inconsistencies in two crucial fields. Fixing this should finally allow us to get over this hideous bug.
Bad news - reproduced this again :(
I tested this in my world (2.6.0-beta3, updated GregTech to 5.09.45.153 and ggfab to 0.3.19). If I read GitHub correctly, those versions should have the fixes.
My testcase setup:
3 Industrial Electrolyzers:
- A: Standalone, with a Stocking ME Input Hatch and an Output Hatch (ME)
- B: Wallshared with C. They share a Stocking ME Input Hatch and an Output Hatch (ME)
- C: Wallshared with B
Both Stocking Input Hatch (ME) are set to stock: Filled Praseodymium Extracting Nano Resin, and Filled Samarium Extracting Nano Resin.
A Digester and MCRs are producing the nano resin. The nano resin is stored in fluid cells in AE2, and is recycled through the process. As such, there are relatively small quantities and the Electrolyzers are able to fully process all fluids, leaving none in the system.
Result: The Electrolyzers crashed seemingly at random - all 3 of them crashed at least once in my ~10 min test. I even saw several cases where B or C crashed but the pair (using the same hatch) kept running just fine. Possible observation: I don't think I ever had all 3 crashed at the same time. It seemed like when there was only 1 running it tended to be fine (but it also couldn't keep up with production so never ran out of fluids to process).
It took a very long time, but I eventually had 2 MCRs crash - The MCRs do not wallshare and each have their own Stocking Input Hatch (ME). Each of these hatches is set to stock a single fluid.
Additional tests: I thought that maybe there was something on my main net that could be interfering, so I moved the whole setup to a subnet that has no read access to the mainnet (it is connected to the mainnet with an Insert Only Fluid Storage Bus on a Dual Interface so that it can push fluids out). Storage was 2x 64k ME Multi-Fluid Storage Cells.
Same behavior persisted - Electrolyzers continued to crash.
I removed the Dual Interface connecting the subnet to the mainnet, thus completely isolating the AE2 network. Same behavior - Electrolyzers continued to crash.
Final Notes:
Crashing seems to happen much more frequently when stocking multiple fluids and they are fluids that can fully empty out of the AE2 system. Reducing the stocking size to 1 makes the setups run for much longer before crashing.
If it did "turned off due to crash" please post the log
Sorry, to clarify it wasn't saying that it crashed, but that it failed to extract from the stocking hatch. The server log had no stacktrace or unusual output (just reporting the online players over and over).