One more note: try debugging the project and see if ti does make sense. It could be that you have a missmatch between binary and symbols file, so debugger points to the wrong place in file.
I mean “isolated, minimum project which reproduces the problem every time for everyone” by solid repro. The problem occurs every time on my working project which is too big and can’t be sent. I’m trying to make a simple/small repro but using Mathf.Lerp() itself didn’t make the problem.
From the image on the initial post, I understand surely Mathf.Lerp() in Assembly-CSharp-firstpass.dll throws the exception. Plus, it went into catch block and logged the error after resume. I also analyzed inside Mathf.Lerp() but I couldn’t find anywhere possibly throws the NRE.
So I tried to implement Lerp() outside Mathf. However, it is getting more weird.
“Avoid calling Mathf.Lerp()” didn’t solve the problem. NRE still thrown as follows:
Each values are not null. So the line is not correct.
I checked the debug output right before the NRE. It was as follows:
So the NRE was thrown after the process exit from Clamp01().
However, I still have no idea WHAT IS NULL.
Still investigating. I appreciate your comment.
p.s.
I wiped and rebuilt /Library folder, wiped project output folder, rebuilt the VS project to avoid symbol mismatch. I have never seen symbol mismatch error in debug output.
I found where is null. The value named “value” was actually a property and source of the property was null.
I expected that a debugger would detect in property part if an exception was thrown in property part. But a project which exported from Unity seems it behaves slightly different.
While an exception is detected right away even in property part for common Visual Studio project, debugger detects after exit property part for project exported by Unity, as following pictures show.
It more likely inlined and optimized the property getter, so the null reference exception actually did occur in the caller function as far as the debugger was concerned.
