I have my single player AE network extended into the Deep Dark. Each time I zone in there now, I get this AE crash, if I restart FTB Infinity Evolved 2.4.2, I arrive correctly and can continue.

It's also worth noting that some of the Quantum Tunnels have unexplained, intermittent downtime every minute or so, for a few seconds. Both my power source and main AE compute facility in the overworld have have chunk loaders.

Time: 4/7/16 11:46 PM
Description: Unexpected error

java.lang.NullPointerException: Unexpected error
at appeng.me.cluster.implementations.QuantumCluster.onUnload(QuantumCluster.java:72)
at cpw.mods.fml.common.eventhandler.ASMEventHandler_1389_QuantumCluster_onUnload_Unload.invoke(.dynamic)
at cpw.mods.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:54)
at cpw.mods.fml.common.eventhandler.EventBus.post(EventBus.java:140)
at net.minecraft.client.Minecraft.func_71353_a(Minecraft.java:2153)
at net.minecraft.client.Minecraft.func_71403_a(Minecraft.java:2146)
at net.minecraft.client.network.NetHandlerPlayClient.func_147280_a(NetHandlerPlayClient.java:874)
at net.minecraft.network.play.server.S07PacketRespawn.func_148833_a(SourceFile:32)
at net.minecraft.network.play.server.S07PacketRespawn.func_148833_a(SourceFile:13)
at net.minecraft.network.NetworkManager.func_74428_b(NetworkManager.java:212)
at net.minecraft.client.multiplayer.PlayerControllerMP.func_78765_e(PlayerControllerMP.java:273)
at net.minecraft.client.Minecraft.func_71407_l(Minecraft.java:1602)
at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:973)
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:898)
at net.minecraft.client.main.Main.main(SourceFile:148)
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:483)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
at net.minecraft.launchwrapper.Launch.main(Launch.java:28)

I just got an identical crash leaving the Twilight forest for the Overworld. That dimension has another identical quantum tunnel set up to link with the Overworld.

For versioning clarity FTB IE 2.4.2 contains:

appliedenergistics2-rv3-beta-5.jar

Here is the function that is crashing: (the NULL deref is from the if statement, could be "this","e", or maybe "this.center"). Perhaps validate all of them before dereferencing?

https://github.com/AppliedEnergistics/Applied-Energistics-2/blob/master/src/main/java/appeng/me/cluster/implementations/QuantumCluster.java line 72

@SubscribeEvent
public void onUnload( final WorldEvent.Unload e )
{
    if( this.center.getWorldObj() == e.world )
    {
        this.setUpdateStatus( false );
        this.destroy();
    }
}

can you send a full crashlog pasted via pastebin or as attachment please? there may be external circumstances provoking this error.

also can you confirm your quantum bridges are completely inside one chunk or do they cross chunkborders?

Single player world crash from leaving overworld to DeepDark:

http://pastebin.com/emmuyQ9v

The one in the Twilight Forest was entirely within one chunk. (It crashed upon leaving that dimension).
None of the other Quantum Tunnels span chunks either.

All of the stacks from the crash dumps are essentially the same.

Does requiring this.center to be non-null, imply that the Quantum Tunnel always has to have a center chamber or that it always has to have an active entangled singularity? Line 256 does NULL center out in the Destroy() method.

SPECULATION:
I wonder if single player dimension/chunk unloading/reloading is somehow different than multiplayer. I am seeing issues with some tunnel connections being broken every 45 seconds and then being restored after 5 seconds of downtime (likely unload related?). Further, I also wonder if having Quantum Tunnels without a singularity inserted yet can cause problems like this.

             * An unknown AE2 API is installed (rv3 from appliedenergistics2-rv3-beta-5.jar).
                Ender IO was build against API version rv2 and may or may not work with a newer version.
              * The RF API that is being used (1.7.10R1.0.2 from <unknown>) differes from that that is reported as being loaded (1.7.10R1.0.7 from StevesAddons-1.7.10-0.10.16.jar).
                It is a supported version, but that difference may lead to problems.
             This may have caused the error. Try reproducing the crash WITHOUT this/these mod(s) before reporting it.

just as an idea, can you first maybe try to fix your mod versions? maybe this solves your problem already ? or you can check if you have any mod interactions that may cause an strange update behaviour?

I get this very consistently now, zoning in or out of any of the dimensions. It's always the same crash stack. I removed the "extra" quantum rings that had no singularity in them yet.

It's worth a try. I'm not running a random MODPACK, this really is FTB Infinity Evolved with just Optifine added. I will move to the latest release version of FTB IE and try that. If that doesn't work, I'll try some of the other newer beta releases.

That being said, the code that I highlighted in the unload handler is not checking for NULL values before dereferencing pointers. That's pretty much a coding issue.

i don't argue about that :) i am just guessing to improve things as nobody answered until yet

i am not familiar enough with all the logic dependencies and what thing never could possibly occur by logic but by accident :)

and to be honest .. the issues with those mod version clashing in such large scale modpacks is the reason for me to not use those and make my own :)

It still crashes exactly the same way with a fresh version of FTB IE 2.5.0 with no other mods or even resource packs loaded.

Also, maybe try without optifine. My assumption might be completely wrong but nobody knows what optifine is really doing.

I worked around this crash by forcing ALL overworld chunks containing Quantum Tunnels to remain loaded. This was done by ctrl-left clicking on chucks(max 50) in the FTBU "claim chunks" map-like UI. Since the Quantum Tunnels are now never unloaded before leaving the overworld, I don't see the crash.

P.S.> The various Railcraft chunk loaders ("anchors") were disabled in FTB IE 2.4.2/2.5.0.

Forcing all Quantum Tunnels to remain chunk loaded is clearly a temp workaround.

Optifine in a single player instance is very likely an issue as it changes the chunkloading. If enabled even to a multithreaded one and considering that nothing in MC is threadsafe, it is pure luck should it work. Fastcraft might also be an idea to look at.

I am a bit curious, if your background is mostly C/C++ based, because assuming this being null is a common misconception. (It is guaranteed to never be null).

e being null would be a major bug most likely on forge side and can put any callee into a potentially unrecoverable state. Therefore simply crashing is the best option. We could check it, but there is really not difference in throwing an implict or explicit NPE.

this.center can actually be null. But it is impossible to be null, when calling onUnload. Which is a simple listener method and will only be called after it explicitly register itself. Which is done in QuantumCluster.java#L282-L287, which also sets this.center to a non null value.
The only exception here would be, if something suddenly introduces multithreading and forces a world unload after the listener is registered but before the QNB is fully assembled.
Changing the order might solve it, but it most likely only hides other issue. Multithreading a non thread safe environment could really result in some bad stuff. Especially if it happens during serialisation, while the state is still being deserialised.

I tried it last with no other mods than what is included in FTB IE 2.4.2 and also 2.5.0. Optifine was not part of the last set of testing.

Indeed, I've written mostly C/C++ code (since about 1980). But also a large variety of other third & fourth gen languages. I know that objects should never have invalid this pointers -- but guaranteed is a strong word when dealing with pointers. And that's from having developed shipping debuggers.

I agree that this.center is the most likely culprit. Based on my workaround of preventing the overworld chunks containing the QuantumCluster objects from unloading, it would seem that switching dimensions with the QuantumCluster objects in unloaded chunks causes the crashes. Perhaps the unload handler is called both upon chunk unload and upon dimension unload? Or perhaps the object was already freed and there was a dangling reference to it?

The simplest answer would be to add some non-null validation for the pointers starting with this.center perhaps. I would be glad to help try this out if you don't have a test case handy.

The JVM/Java specs define that it has to throw a NPE before invoking a method on null. Thus this is always guaranteed to be not null. Similar to constructors always returning an object instance or throwing an exception. So no need to verify that explicitly in java.
As java is also a managed language, as long as there is a single hard and reachable reference to an object, it will never be freed (except things like out of memory..). Pretty much most C/C++ memory handling issues will not apply to java, so they can simply be ignored.

this.center is clearly the issue, but as said it can only happen in a multi threaded environment. Which normal chunk loading is not. Adding a null check would just hide it, but not solve the real issue. Potentially also leave some dangling network connections around, which could cause further issues.

I personally still do not really trust FTBU and therefore looked at their code.
Which is actually loading chunks in a separate thread. A really bad idea in a non threadsafe environment... I would not be surprised, if this could also cause other issues like inventories not being correctly serialised and dupe or loss items due to it.
It will also only happen in singleplayer.

I can close this issue if you prefer. But I will say that FTB IE (~170 mods) only crashes with this one stack so far -- and it's very easily reproducible.

Keeping it open is probably ok. I pinged the FTBU dev on IRC. But no real response for now and it certainly should be communicated to him.

It should be pretty easy to at least stop it from crashing. But the real question is "is it better to turn a crash into something unknown?" or not. "Unknown" could also mean slow chunk corruption or similar issues.