Null pointers in BetterList and UIPanel

[ryan]

We're in the middle of debugging an issue here that I think is related to unloading some bundles, which has exposed some NullReferenceExceptions in BetterList.Contains and UIPanel.GetDrawCall:

1. NullReferenceException: Object reference not set to an instance of an object
2.   at BetterList`1[UnityEngine.Material].Contains (UnityEngine.Material item) [0x00000] in <filename unknown>:0
3.   at UIPanel.UpdateTransforms () [0x00000] in <filename unknown>:0
4.   at UIPanel.LateUpdate () [0x00000] in <filename unknown>:0
5.  
6. NullReferenceException: Object reference not set to an instance of an object
7.   at UIPanel.GetDrawCall (UnityEngine.Material mat, Boolean createIfMissing) [0x00000] in <filename unknown>:0
8.   at UIPanel.Fill (UnityEngine.Material mat) [0x00000] in <filename unknown>:0
9.   at UIPanel.LateUpdate () [0x00000] in <filename unknown>:0
10.  

The BetterList error should be easy to fix:

1. for (int i = 0; i < size; ++i) if (buffer[i] != null && buffer[i].Equals(item)) return true;
2.  
3. instead of
4.  
5. for (int i = 0; i < size; ++i) if (buffer[i].Equals(item)) return true;
6.  

Unfortunately no line numbers are available in the builds we've seen this in, but I think a null material is sneaking in somewhere when we unload some bundles containing our UI, so UIPanel.GetDrawCall is probably failing on:

1. GameObject go = new GameObject("_UIDrawCall [" + mat.name + "]");

Whether or not that should be fixed, or how best to fix it without a reliable repro, I'll leave up to you.  That specific error is easy enough to guard against, but if UIDrawCall instances are left hanging around with null materials, that's obviously a bad state that we shouldn't be letting NGUI get into.  We're working on fixing the source of the problem in our code, but I figured these were worth pointing out in case you wanted to deal with them.

[ArenMook]

You're unloading an asset bundle containing the material used by the UI while the UI is still in use?

[ryan]

Not intentionally, but I think that's pretty much what was happening.  I'm a little hazy on the details, because somebody else was working on fixing it, but I think the problem on our side was that we had class A asking class B to destroy a portion of the UI, and then class A proceeded to unload the bundle containing that UI, while class B was waiting until the next Update to actually destroy the UI.  This probably also involves that other bug I mentioned a while ago about OnDestroy not getting called on objects that are destroyed as a result of their bundle being unloaded.