Immersiveengineering: New crash version 44, Wires crashing server once restarted

[blkwind]

The new mod version loaded into the server great, however as soon as i restart the server after testing all the blocks and machines I get this error and crash.

WARNING: coremods are present:
SpongeCoremod (spongeforge-1.10.2-2092-5.0.0-BETA-1758.jar)
EnderCorePlugin (EnderCore-1.10.2-0.4.1.56-beta.jar)
IC2core (industrialcraft-2-2.6.61-ex110.jar)
LoadingPlugin (ResourceLoader-MC1.9.4-1.5.1.jar)
OFMDepLoader (OpenFM-1.9.4-0.1.0.11.jar)
LoadingHook (Mekanism-1.10.2-9.2.0.292.jar)
MalisisCorePlugin (malisiscore-1.10.2-4.2.2.jar)
LoadingPlugin (RandomThings-MC1.10.2-3.7.6.jar)
LoadingPlugin (Quark-r1.0-55.jar)
TransformerLoader (OpenComputers-MC1.10.2-1.6.0.3-rc.1.jar)
CCLCorePlugin (CodeChickenLib-1.10.2-2.2.3.73-universal.jar)
BookshelfLoadingPlugin (Bookshelf-1.10.2-1.4.2.325.jar)
MalisisSwitchesPlugin (malisisswitches-1.9.4-3.0.0.jar)
ShetiPhian-ASM (shetiphiancore-1.10.0-3.3.0.jar)
DepLoader (BrandonsCore-1.10.2-2.1.0.46-universal.jar)
Contact their authors BEFORE contacting forge

// Shall we play a game?

Time: 10/9/16 9:22 PM
Description: Exception in server tick loop

java.lang.NullPointerException: Exception in server tick loop
at blusunrize.immersiveengineering.api.energy.wires.TileEntityImmersiveConnectable.func_145829_t(TileEntityImmersiveConnectable.java:268)
at net.minecraft.world.chunk.Chunk.func_177426_a(Chunk.java:819)
at net.minecraft.world.chunk.Chunk.func_150813_a(Chunk.java:798)
at net.minecraft.world.chunk.storage.AnvilChunkLoader.loadEntities(AnvilChunkLoader.java:490)
at net.minecraftforge.common.chunkio.ChunkIOProvider.syncCallback(ChunkIOProvider.java:96)
at net.minecraftforge.common.chunkio.ChunkIOExecutor.syncChunkLoad(ChunkIOExecutor.java:94)
at net.minecraft.world.gen.ChunkProviderServer.loadChunk(ChunkProviderServer.java:115)
at net.minecraft.world.gen.ChunkProviderServer.func_186028_c(ChunkProviderServer.java:86)
at net.minecraft.world.gen.ChunkProviderServer.func_186025_d(ChunkProviderServer.java:132)
at net.minecraft.world.World.func_72964_e(World.java:303)
at com.rwtema.extrautils2.chunkloading.XUChunkLoaderManager.ticketsLoaded(XUChunkLoaderManager.java:207)
at net.minecraftforge.common.ForgeChunkManager.loadWorld(ForgeChunkManager.java:604)
at net.minecraftforge.common.ForgeInternalHandler.onDimensionLoad(ForgeInternalHandler.java:83)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_6_ForgeInternalHandler_onDimensionLoad_Load.invoke(.dynamic)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90)
at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:130)
at org.spongepowered.mod.event.SpongeForgeEventFactory.callWorldLoadEvent(SpongeForgeEventFactory.java:1247)
at org.spongepowered.mod.event.SpongeForgeEventFactory.callForgeEvent(SpongeForgeEventFactory.java:431)
at org.spongepowered.mod.event.SpongeModEventManager.post(SpongeModEventManager.java:329)
at org.spongepowered.mod.event.SpongeModEventManager.post(SpongeModEventManager.java:381)
at org.spongepowered.mod.event.SpongeModEventManager.post(SpongeModEventManager.java:366)
at org.spongepowered.common.SpongeImpl.postEvent(SpongeImpl.java:140)
at org.spongepowered.common.world.WorldManager.createWorldFromProperties(WorldManager.java:810)
at org.spongepowered.common.world.WorldManager.loadAllWorlds(WorldManager.java:752)
at net.minecraft.server.MinecraftServer.func_71247_a(MinecraftServer.java:322)
at net.minecraft.server.dedicated.DedicatedServer.func_71197_b(DedicatedServer.java:266)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:431)
at java.lang.Thread.run(Unknown Source)

Here is a link to the full crash file.
http://pastebin.com/0v6Uj5PD

[Ristellise]

try without spongeforge. also next rime do not post a wall of text like the above to github.

[mindforger]

funny O_o did extrautils switch the way they are doing their chunkloading, this looks like the case when using chickenchunks in the past to me

i partially doubt this is a sponge issue, because i have no insight on the current XU code yet but if not changed, there is nothig that should falsely propagate through or maybe an race condition !?

Whoops wrong line, this totally looks like a race condition, the INSTANCE is gone again or yet not loaded while the world is beeing loaded for some reason !?

@BluSunrize i'd recommend to replace all your static self references by a static "getInstance()" with a null check and maybe a sane debug output to get behind those strange issues

i doubt it highly but the JVM option "CMSClassUnloadingEnabled" could be a reason possible? Especially in early startup stages while many many accesstransformations an on demand class extensions are done the permgen runs full pretty fast and the GC maaay kill your INSTANCE then !?

[blkwind]

Sorry for the "Wall of text" was just trying to give a quick glimpse of the crash so people didn't have to click a link to get an idea of the actual crash was. I am assuming the error has to due with the change to Wire Api listed in the changlog for version 43 and 44. Especially sense this error didn't exist pre version 43 and the first string being "blusunrize.immersiveengineering.api.energy.wires.TileEntityImmersiveConnectable.func_145829_t(TileEntityImmersiveConnectable.java:268)"

[malte0811]

I am quite sure that the API change is unrelated, it is only relevant when removing wires and would not cause this sort of crash. I will take a look at XU's chunkloading later today.

[AEnterprise]

i don't think the GC removed the INSTANCE as it is stored in static variable. One way to make sure is to also make the field final, the GC isn't alowed to remove static final fields at all

[mindforger]

i don't think the GC removed the INSTANCE

i was guessing it removed the whole class including the INSTANCE ... this is easily possible when there is no pending reference and a forced full GC is ongoing .. but it also requires this particular flag to be set ... maybe sponge sts it inherrently ?! But the Idea with the final is a golden one, i totally forgot about when and why final attribute is to be used, this one is definately a perfect spot! (unless removed by some classhacking other mod XD)

[AEnterprise]

i don't know exactly how the INSTANCE initiallised but yes it could have removed the class but as the class has a static self reference that should only heapen if the GC was performing an extremely agressive cleanup (would only heapen with a critical memory shortage)

[malte0811]

YAY! I finally managed to reproduce this, took nearly 2 hours (but about half of that time was spent on understanding chunkloading code). It happens when there is an IE wire being loaded by a XU chunkloader in the first dimension that is loaded. The fix is pretty easy, I just need to initialize ImmersiveNetHandler.INSTANCE directly after declaring it (I'm making it final as well, but that shouldn't really be necessary). I will push the fix later today, but I just found some wire rendering weirdness that I want to look into first.

[mindforger]

this sure will fix a lot of issues :D that are still open

[BluSunrize]

@malte0811 can you confirm that this keeps all saving and loading of wires working correctly?

[malte0811]

It should not change anything, the only write accesses to that variable were the initialisations I removed (according to eclipse). Both of those had the condition INSTANCE==null, so once the instance was initialised, it wasn't ever changed. My commit just makes this initialisation happen earlier, but since no MC-specific code is run on initialising the INSTANCE, that should not matter.

[mindforger]

i'll adhere again my proposal for a solution with more stability

do not call INSTANCE from public
give it a static getINSTANCE()
check there and instantiate properly if still null
load everything and also check if the serverstate is in any way applicable to load everything (I understand @BluSunrize concerns there)
return the INSTANCE

or throw a sane message to indicate someone provoking to load INSTANCE with invalid server state :)

[blkwind]

If its possible to get me a copy of a mod file with the fix I would be happy to test it for you and confirm wires still work. Thanks again guys, my server seems to be great at finding all the rare bugs. =P