I found this error from my Steam game which released to players, and the could diagnostic captured this seemingly impossible NRE.I brushed it off the first or second time, but this is like third time from different places of code, so I thought I would seek knowledge from forum.
This is what error reported and call stack looks like, hmm a simple NRE…
But when I go to that code site, the NRE in question is clearly just right behind the null check.
The m_PendingCreationDeserialize is type of byte[ ] which is not special class or anything.
If you look at the call stack from first image, the code was calling from GameObject’s Update() so this is surely on main thread and I’m 99% sure no multithread shenanigan happening here that would race to write m_PendingCreationDeserialize
And from searching references, the only place that set it null is here.
The other place should also calling from main thread, it was from Mirror’s (the networking lib) network data callback, which called from LateUpdate.
If anyone has a hunch or weird knowledge or idea to share on this I would be appreciated.
This occurrence has ruined my believe that there isn’t quantum or Schrodinger variable involved!
It’s very suss. If the array was a null reference due to some multithreading shennanigans, ArraySegment.ctor shouldn’t be throwing a NullReferenceException, it should be throwing an ArgumentNullException, see the docs.
Which means that either there’s a bug in the implementation of ArraySegment (unlikely), or there’s a bug in the report itself - ie. that it’s reporting the wrong stack trace.
I’m pretty positive the line number is lined up as it points to ctor in question. But yea I will never know what happen on bytecode level around that call. Something could optimize it.
It works, I tried it just in case ^^; ctor can run with the new byte[0] array
That’s interesting, I haven’t thought about that. it would throw a different error.
my gut also told me that it slight chance could be from C# Mono implementation of that Unity version I’m using (2022.1.15) which is quite aged.
Also if it’s a false report I’d be very happy to have it ended that way
Thank you everyone for helping me in this sanity check.
So far it’s good that it happen not to everyone. But if this specific location triggers more same error again then it could not be coincident. so the mystery continues…
TY for the article, I had fun reading it, especially in current state when it happened to me now.
Is that “m_PendingCreationDeserialize” by any chance a property with some dodgy getter code?
It would be great to have at least the fundamental context of the problem. As we can see you only have one line that actually sets the field / property to a value. Where is that line?
It is plain field member in the class.
that’s why I deem it seemingly impossible, unless something else goes on the bytecode or C# Mono lmplementation level.
This error defies my years of C# knowledge and debugging
