Great thank you for reporting. This is an interesting one.
>OnExternalUI is a private function.
Actually the fact that it is private is irrelevant as GC doesn't discriminate on the base of the visibility type. And it is not
You probably noticed my second comment:
This work around was done to keep the
Interestingly enough it is not because of the compiler optimization. Reflector clearly shows that the cal wasn't removed:
![Image]()
But the debugger never visits the line with the condition, meaning that it is JIT who does the damage. It's worth to note that moving the condition below the finally clause restores the power of the work around even though the finally clause scope is not changed in this case:
Anyway it is enough to put any meaningful invoke inside of the condition to fool JIT.
The fix has been committed and will be available with the next release (in a day or so).
Thank you for your feedback.
>OnExternalUI is a private function.
Actually the fact that it is private is irrelevant as GC doesn't discriminate on the base of the visibility type. And it is not
OnExternalUI but uiHandler who get's collected. But it is not where problem is anyway.You probably noticed my second comment:
finally { ... //It is important to reference uiHandler here to keep it alive till the end. //The debug build is more forgiving and referencing uiHandler is not essential as the code is not optimizedif (uiHandler != null) uiHandler = null; }
uiHandler reference alive until the end of the method call. Exactly in the spirit of the stack overflow post you provided. However... To my surprise in the finally scenario the trick is invalidated. Somehow finally screws JIT and the condition for uiHandler is never executed. Interestingly enough it is not because of the compiler optimization. Reflector clearly shows that the cal wasn't removed:
But the debugger never visits the line with the condition, meaning that it is JIT who does the damage. It's worth to note that moving the condition below the finally clause restores the power of the work around even though the finally clause scope is not changed in this case:
finally { ... } if (uiHandler != null) uiHandler = null;
if (uiHandler != null) { Environment.SetEnvironmentVariable("ReasonForThis", "IHadToDoSomethingThatJITWouldNotOptimise"); uiHandler = null; }
Thank you for your feedback.