Bug 11727 - NullReferenceException when cleaning up UIView Subviews
Summary: NullReferenceException when cleaning up UIView Subviews
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 6.2.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2013-04-11 06:59 UTC by Chris Hardy [MSFT]
Modified: 2016-05-24 19:23 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Chris Hardy [MSFT] 2013-04-11 06:59:03 UTC
When running the following code:

for (int i = scrollView.Subviews.Length - 1; i >= 0; i--)
   UIView view = scrollView.Subviews[i];
   view.RemoveFromSuperview ();

this sometimes causes the following exception:

System.NullReferenceException: Object reference not set to an instance of an object
at MonoTouch.ObjCRuntime.Runtime.TryGetNSObject (IntPtr ptr) [0x00000] in <filename unknown>:0
at MonoTouch.ObjCRuntime.Runtime.GetNSObject (IntPtr ptr) [0x00000] in <filename unknown>:0
at MonoTouch.Foundation.NSArray.ArrayFromHandle[T] (IntPtr handle) [0x00000] in <filename unknown>:0
at MonoTouch.UIKit.UIView.get_Subviews () [0x00000] in <filename unknown>:0
Comment 2 Sebastien Pouliot 2013-04-19 12:04:47 UTC
The issue is very unlikely to exists in the code inside comment #1. It's also unclear if the NRE occurs on the first line or the third.

Potential issues are:

a) this code (or another code part) is remove views from another thread - the loop thinks there's on subview left (there was when called) but it's not there (returns null) when accessing the *new* array;

b) there's a memory corruption somewhere in the code. The stacktrace is deeper than I would have expected;

To avoid a race, and limit case (a), the code could be rewritten as:

var subviews = scrollView.Subviews;
for (int i = subviews.Length - 1; i >= 0; i--)
   UIView view = subviews[i];
   view.RemoveFromSuperview ();

That will only call ObjC (for Subviews), and allocate the array once. So any other changes (e.g. by another thread) won't make the array differs between the 1st and subsequent (loop) calls. 

That reduce the likeliness of the issue (if threading related) and make it a bit faster (unlikely to be noticed) since it removes calls and reduce memory allocations.

A crash report from the device(s) where it occurs would be helpful. E.g. it will tell us what other threads are doing.
Comment 3 Tim Dawson 2013-04-19 13:53:33 UTC
Thanks, we will incorporate that change and see if it yields any useful information. I suspect it will not, because there are definitely no other threads attempting to make changes to the UI. Memory corruption is my best guess due to other "strange" and "impossible" exception reports we get daily.
Comment 4 Sebastien Pouliot 2013-04-19 17:31:12 UTC
Hello Tim, It will be most useful (thread-related or not) if we can get a symbolicated crash report.

But if you're getting other weird crash then it makes it even more likely that something might be corrupting memory. Those are harder to catch (without sources). Apple Instruments (or valgrind with the simulator) can be useful in such cases - as they will spot some issues before, even if it does not crash (corrupted memory often "works" making it harder to spot).
Comment 5 Tim Dawson 2013-04-20 16:21:24 UTC
We've never received a crash report from this problem, and never seen it (or any of the dozens of other "impossible" problems) in our own tests. Memory corruption sounds like an ideal candidate, but it's difficult to know what could cause such a thing. Certainly all we're using is managed code, no p/invoke to speak of, and no third-party libraries. The only remotely unusual thing about our setup, as far as I know, is that we're using sgen.

I am familiar with using Instruments to do common things like profiling and tracking allocations; could you be more specific about how we could use it to detect the signs of memory corruption?

Comment 6 Prashant Cholachagudda 2013-10-29 07:15:09 UTC
Managed exception:

Begin Exception NullReferenceException at 2013/10/23 18:27:16
Product: SkyDemon for iPad
MonoTouch: 7.0.0
iOS: 7.0.2
Hardware: iPad2,2
System.NullReferenceException: Object reference not set to an instance of an object
at Divelements.SkyDemon.Briefing.NotamBriefingScreen.ClearTable () [0x00000] in <filename unknown>:0
at Divelements.SkyDemon.Briefing.NotamBriefingScreen.ViewDidDisappear (Boolean animated) [0x00000] in <filename unknown>:0
at (wrapper managed-to-native) MonoTouch.ObjCRuntime.Messaging:void_objc_msgSend (intptr,intptr)
at MonoTouch.UIKit.UIViewController.EndAppearanceTransition () [0x00000] in <filename unknown>:0
at Divelements.SkyDemon.UI.SplitView.set_SelectedViewController (MonoTouch.UIKit.UIViewController value) [0x00000] in <filename unknown>:0
at Divelements.SkyDemon.UI.SplitView.OnAnimationStopped () [0x00000] in <filename unknown>:0
at (wrapper managed-to-native) MonoTouch.ObjCRuntime.Messaging:void_objc_msgSend (intptr,intptr)
at MonoTouch.UIKit.UIView.CommitAnimations () [0x00000] in <filename unknown>:0
at Divelements.SkyDemon.UI.SplitView.DismissViewController (MonoTouch.UIKit.UIViewController viewController) [0x00000] in <filename unknown>:0
at Divelements.SkyDemon.UI.SplitView.PanStopped (PointF velocity) [0x00000] in <filename unknown>:0
at Divelements.SkyDemon.UI.SlidingViewButton.Pan (MonoTouch.UIKit.UIGestureRecognizer sender) [0x00000] in <filename unknown>:0
at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr)
at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x00000] in <filename unknown>:0
at Divelements.SkyDemon.Application.Main (System.String[] args) [0x00000] in <filename unknown>:0
End Exception
Comment 8 Sebastien Pouliot 2016-05-24 19:23:51 UTC
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and re-open the bug report. Thanks!