Happened on a server while nobody was online, upon restarting the server the crash persisted. Had to rollback to an earlier backup. Seems to have happened randomly, there was no change in conduit or OC configuration so I'm guessing it's a chunk-related issue.

Bug with EnderIO or OC itself? The code in Ender IO or OC (especially OC as it's scala) doesn't make much sense to me.

[06:37:11] [Server thread/ERROR]: Encountered an unexpected exception
net.minecraft.util.ReportedException: Ticking block entity
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:642) ~[MinecraftServer.class:?]
at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:334) ~[lt.class:?]
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:547) ~[MinecraftServer.class:?]
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:396) [MinecraftServer.class:?]
at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:685) [li.class:?]
Caused by: java.lang.NullPointerException
at li.cil.oc.server.network.Node$class.connect(Node.scala:38) ~[Node$class.class:?]
at li.cil.oc.server.network.Network$ComponentBuilder$$anon$2.connect(Network.scala:595) ~[Network$ComponentBuilder$$anon$2.class:?]
at li.cil.oc.server.network.Network$$anonfun$add$5$$anonfun$apply$2.apply(Network.scala:269) ~[Network$$anonfun$add$5$$anonfun$apply$2.class:?]
at li.cil.oc.server.network.Network$$anonfun$add$5$$anonfun$apply$2.apply(Network.scala:269) ~[Network$$anonfun$add$5$$anonfun$apply$2.class:?]
at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59) ~[scala-library-2.11.1.jar:?]
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48) ~[scala-library-2.11.1.jar:?]
at li.cil.oc.server.network.Network$$anonfun$add$5.apply(Network.scala:269) ~[Network$$anonfun$add$5.class:?]
at li.cil.oc.server.network.Network$$anonfun$add$5.apply(Network.scala:259) ~[Network$$anonfun$add$5.class:?]
at scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:33) ~[scala-library-2.11.1.jar:?]
at scala.collection.mutable.ArrayOps$ofRef.foreach(ArrayOps.scala:186) ~[scala-library-2.11.1.jar:?]
at li.cil.oc.server.network.Network.add(Network.scala:259) ~[Network.class:?]
at li.cil.oc.server.network.Network.connect(Network.scala:104) ~[Network.class:?]
at li.cil.oc.server.network.Network$Wrapper.connect(Network.scala:734) ~[Network$Wrapper.class:?]
at li.cil.oc.server.network.Node$class.connect(Node.scala:38) ~[Node$class.class:?]
at li.cil.oc.server.network.Network$NodeBuilder$$anon$4.connect(Network.scala:583) ~[Network$NodeBuilder$$anon$4.class:?]
at crazypants.enderio.conduit.oc.OCConduit.addMissingNodeConnections(OCConduit.java:386) ~[OCConduit.class:?]
at crazypants.enderio.conduit.oc.OCConduit.setNetwork(OCConduit.java:206) ~[OCConduit.class:?]
at crazypants.enderio.conduit.AbstractConduitNetwork.setNetwork(AbstractConduitNetwork.java:48) ~[AbstractConduitNetwork.class:?]
at crazypants.enderio.conduit.AbstractConduitNetwork.setNetwork(AbstractConduitNetwork.java:54) ~[AbstractConduitNetwork.class:?]
at crazypants.enderio.conduit.AbstractConduitNetwork.setNetwork(AbstractConduitNetwork.java:54) ~[AbstractConduitNetwork.class:?]
at crazypants.enderio.conduit.AbstractConduitNetwork.setNetwork(AbstractConduitNetwork.java:54) ~[AbstractConduitNetwork.class:?]
at crazypants.enderio.conduit.AbstractConduitNetwork.setNetwork(AbstractConduitNetwork.java:54) ~[AbstractConduitNetwork.class:?]
at crazypants.enderio.conduit.AbstractConduitNetwork.setNetwork(AbstractConduitNetwork.java:54) ~[AbstractConduitNetwork.class:?]
at crazypants.enderio.conduit.AbstractConduitNetwork.setNetwork(AbstractConduitNetwork.java:54) ~[AbstractConduitNetwork.class:?]
at crazypants.enderio.conduit.AbstractConduitNetwork.setNetwork(AbstractConduitNetwork.java:54) ~[AbstractConduitNetwork.class:?]
at crazypants.enderio.conduit.AbstractConduitNetwork.init(AbstractConduitNetwork.java:36) ~[AbstractConduitNetwork.class:?]
at crazypants.enderio.conduit.ConduitUtil.ensureValidNetwork(ConduitUtil.java:57) ~[ConduitUtil.class:?]
at crazypants.enderio.conduit.AbstractConduit.updateNetwork(AbstractConduit.java:479) ~[AbstractConduit.class:?]
at crazypants.enderio.conduit.AbstractConduit.updateEntity(AbstractConduit.java:426) ~[AbstractConduit.class:?]
at crazypants.enderio.conduit.TileConduitBundle.doUpdate(TileConduitBundle.java:254) ~[TileConduitBundle.class:?]
at com.enderio.core.common.TileEntityEnder.func_145845_h(TileEntityEnder.java:45) ~[TileEntityEnder.class:?]
at net.minecraft.world.World.func_72939_s(World.java:1939) ~[ahb.class:?]
at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:489) ~t.class:?]
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:636) ~[MinecraftServer.class:?]
... 4 more

Derpiness

Nevermind, missed a few lines when copying the trace into text editor for unwrapped reading...

Looks like this is happening when merging networks containing nodes with the same addresses, and something goes wrong while re-assigning addresses... so yeah, this might be an issue in OC. I'll look into.

There are 16 nodes per conduit-network, one per color. A conduit-network consists of all conduits that are connected to each other. The conduit-network initializes them in its constructor with joinNewNetwork(), so unless a node quits being in one for some reason, "our" nodes are always in an oc-network.

However, shouldn't it NPE in at li.cil.oc.server.network.Network.connect(Network.scala:104) ~[Network.class:?] if our node had no network?

@cosmicdan Did you make a copy of the crashing version of the work? It may be worth it to make a debug version of Ender IO to let it crash with lots of debug output. That's always better than wildly guessing what may have gone wrong.

Yeah, see edit. It's something in the network merging code of OC that triggers when there's duplicate addresses. Which shouldn't really be possible in the first place (except when copying items with a stored address e.g.), so that part of the network logic is... rarely executed, so it's quite likely a dormant bug in OC.

Duplicate addresses? That sounds like something that must happen when loading chunks with Minecraft ;). May be triggered by EIO rebuilding its network and having its single node connected to many different blocks.

Yes I have kept the crashing world, would be happy to test with a debug build.

Duplicate addresses? Hmm. I wonder if this is related, then. Sometimes I need to move a particular OC component and the addresses for other components on the same network randomly change. Random as in, in my example, half of my pebble bed reactor cores will have their addresses changed, the other half will be the same, after removing and replacing an OC conduit that is connected elsewhere.

Sorry for going off topic, but I'm wondering if that could be an issue with OC conduits or just OC itself? OC seems a bit hit and miss with other areas E.g. using multiple screens, one will randomly stop working, but I digress.

On 6 Jan 2016, Henry Loenwind [email protected] wrote:

Duplicate addresses? That sounds like something that must happen when
loading chunks with Minecraft ;). May be triggered by EIO rebuilding
its network and having its single node connected to many different
blocks.

---

Reply to this email directly or view it on GitHub:
#3109 (comment)

Sent with K-@ Mail - the evolution of emailing.

@fnuecke any news on this?

Sorry for the delay, didn't have a lot of free time the last days; I'm hoping to find the cause and fix it this weekend.

@fnuecke Checking in?

Hey, terribly sorry for the delay. I did look into this some more, but found no obvious reason why this might happen, yet :/ I did find one bug in the merge logic for duplicate addresses, though I'm not convinced it's related. Cleaned it up some and did some testing and it doesn't seem to break anything else, so if someone who can reproduce this could test the latest OC dev build for me to see if it is, I'd appreciate that (available on my Jenkins, build 866 or newer). Note that this is OC 1.6, which is still WIP, so please make a backup first, if you give it a shot. Thanks.

Again, very sorry for the delay.

Allright, I finally was able to come up with a test case where I could reproduce the error (well, an NPE at that location at least), and fixed it now. I'm 99.351% sure this fixes this issue. Sorry it took so long, but between lack of time and this being a bit of a tricky bug (that I was never able to reproduce with EIO, just finally today with a unit test after coming up with the specific scenario that could lead to the error) I just wasn't able to fix it much sooner.

For those interested, the problem was with nodes being removed during a remapping operation (when merging networks containing different nodes with the same address, one of them has to change its address). This can happen if an Environment removes a node in its onDisconnect which is the case for some 'driver filesystems' in OC, for example.

That still leaves the oddity that multiple nodes even have the same address; they're generated UUIDs after all... most likely case is multiple nodes being loaded from the same NBT tag. But in the case of the conduits it doesn't really matter, since their nodes are never addressed by anything, and now it shouldn't crash anymore either, so whatever :P

The fix is in the latest OC devbuild.

Sorry to bother @fnuecke - just wondering if this fix made it into the 1.6.0.3-rc.1 release? Or do we have to use the dev builds still?

Regardless, thanks so much for sorting this out!

Yep, the fix is in the RC!