Crash with Cofh?
mcenderdragon opened this issue ยท 14 comments
From towncraft or something, it happens as soon as someone tries to join a server.
Full Crash: https://gist.github.com/ProsperCraft/6fbe885aa489db2b41ec6765c2b5eaa9
java.lang.NullPointerException
at cofh.thermaldynamics.duct.attachments.servo.ServoItem.insertItem(ServoItem.java:399)
at cofh.thermaldynamics.duct.attachments.servo.ServoItem.insertItem(ServoItem.java:468)
at net.minecraftforge.items.ItemHandlerHelper.insertItem(ItemHandlerHelper.java:45)
at futurepack.common.block.logistic.InventoryExtractor.tryExtractIntoInv(InventoryExtractor.java:84)
at futurepack.common.block.logistic.InventoryExtractor.doItemExtract(InventoryExtractor.java:40)
at futurepack.common.block.TileEntityModificationBase.doUpdate(TileEntityModificationBase.java:354)
at futurepack.common.block.TileEntityModificationBase.update(TileEntityModificationBase.java:199)
at net.minecraft.world.World.redirect$tileEntityUpdate$zbb000(World.java:4131)
at net.minecraft.world.World.updateEntities(World.java:1835)
at net.minecraft.client.Minecraft.runTick(Minecraft.java:1846)
at net.minecraft.client.Minecraft.runGameLoop(Minecraft.java:1097)
at net.minecraft.client.Minecraft.run(Minecraft.java:3941)
at net.minecraft.client.main.Main.main(SourceFile:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
@KingLemming I am doing a isEmpty() on the ItemStack I am passing to ItemHandlerHelper so I guess the problem is in the Helper or in the cofh.thermaldynamics.duct.attachments.servo.ServoItem.insertItem method.
Given that this doesn't happen with other mods, Occam's Razor applies. You may well be calling isEmpty, but it sure looks like you are pushing in a null item from the stacktrace.
And no its not possible for the stack to be null, as other mods would also crash. The code in question:
ItemStack it = invBase.extractItem(i, 64, true);
if(it!=null && !it.isEmpty())
{
float f = 0;
ItemStack rest = ItemHandlerHelper.insertItem(handler, it, true);
if(rest==null || rest.isEmpty())
{
after reading https://github.com/CoFH/ThermalDynamics/blob/1.12/src/main/java/cofh/thermaldynamics/duct/attachments/servo/ServoItem.java#L398 it seems like the filter is null @KingLemming is this possible when other (core)mods are involved too ?
I looked at that yesterday. It shouldn't be possible at all. The filter is created in the constructor. If a mod actively attacks TD in some way and nulls out our filters then uh...okay, sure.
And, this is the first report of something like this ever happening.
So both of us are seeing this type of null crash for the first time & we agree under normal condition this is not possible ?
Why in the world would you execute an item send on the client side?
But yes, the filter should be there. Even if for some reason it were not, the error is a mod doing server side logic on the client.
@KingLemming is it possible (though an NBT/chunk save bug) the filter is lost and not restored after chunk load ? Also this crash only happens client side. Does the client side has a filter ?
To my knowledge the IInventoryCapability defined nowhere to only use it server side, and I do this to reduce network load needed for pipe syncronisation. (I am the one who made PRs optimising mod traffic, because of horrible slow german internet connections)
Is the client using https://github.com/CoFH/ThermalDynamics/blob/1.12/src/main/java/cofh/thermaldynamics/duct/AttachmentRegistry.java#L63 to create an instance of the ServoItem ? If so, the filter gets never created due to the super file: https://github.com/CoFH/ThermalDynamics/blob/1.12/src/main/java/cofh/thermaldynamics/duct/attachments/ConnectionBase.java#L59.