I finally narrowed this down to a smaller test case that shows what I think is a bug. Here is the bug report: https://bugzilla.xamarin.com/show_bug.cgi?id=6338
The missing piece from my previous attempts to reproduce it in a smaller example was a UINavigationController. Having one of those in the picture is somehow convincing the runtime that it needs to reconstruct my managed object, and I don't think it should need to in this case. I have a workaround now (dispose the navigation controller as well), but I filed the bug report anyway so maybe someone can explain what's going on. Thanks. -- Adam Kemp adam.k...@ni.com (512) 683-6058 Nic Wise <n...@fastchicken.co.nz> wrote on 07/30/2012 04:05:54 PM: > From: Nic Wise <n...@fastchicken.co.nz> > To: Adam Kemp <adam.k...@ni.com> > Cc: monotouch@lists.ximian.com, Rolf Bjarne Kvinge > <r...@xamarin.com>, Sebastien Pouliot <sebast...@xamarin.com> > Date: 07/30/2012 04:05 PM > Subject: Re: [MonoTouch] When to implement Foo(IntPtr) constructors > > Hi Adam > > If you have a reproducible case, make a bugzilla bug with it > (bugzilla.xamarin.com) and email support@xamarin with a reference to > it. They can then assign it to the right person to have a look at. > > Thanks > > Nic > > > > On Mon, Jul 30, 2012 at 2:26 PM, Adam Kemp <adam.k...@ni.com> wrote: > > Thanks for the response, Nic. That explanation makes sense to me, but it > > doesn't really answer why in this particular case the MonoTouch runtime > > wants to resurrect the managed object. I am in fact releasing my last > > reference to that object, but that is because I really am completely done > > with it. It should actually be leaving memory. That is, when that managed > > reference goes away the unmanaged reference should leave memory as well. > > > > What's happening in this case is that the UIViewController base class > > subscribes to a notification for low memory warnings. I am releasing my > > last managed reference to this view controller in my own handler for low > > memory warnings (in a different view controller), but something (perhaps > > an autorelease call?) is keeping the view controller I want to go away to > > stay in memory long enough to want to handle that low memory notification. > > This is the behavior that I can reproduce in a test project. However, in > > my test project I can only get it to reproduce if I override ViewDidUnload > > or DidReceiveMemoryWarning in the view controller that I want to go away. > > In my real project I didn't implement either one of those, and yet it is > > being resurrected anyway. As I said, the only method I override in this > > view controller class is ViewDidLoad, and that method is not being called. > > Why would the runtime try to reconstruct the managed object if it's not > > needed by anything? If I could get some kind of hint in the debugger about > > why it's being reconstructed then that would help. > > > > My main concern is that in this case if I can't release the reference to > > this view controller here then I'm not sure where I could safely release > > it. The view controller is no longer on screen. It shouldn't be referenced > > by anything else. There's no reason I can think of that it shouldn't be > > safe to allow it to leave memory at this point. I'd like to get to the > > bottom of why it is being resurrected. > > -- > > Adam Kemp > > adam.k...@ni.com > > (512) 683-6058 > > > > Nic Wise <n...@fastchicken.co.nz> wrote on 07/30/2012 01:01:26 PM: > > > >> From: Nic Wise <n...@fastchicken.co.nz> > >> To: Adam Kemp <adam.k...@ni.com> > >> Cc: monotouch@lists.ximian.com, Sebastien Pouliot > >> <sebast...@xamarin.com>, Rolf Bjarne Kvinge <r...@xamarin.com> > >> Date: 07/30/2012 01:01 PM > >> Subject: Re: [MonoTouch] When to implement Foo(IntPtr) constructors > >> > >> Hi Adam > >> > >> You really need a reply from Rolf or Sebastian, but they are in Boston > >> at the moment at the (annual?) company meetup. I've CCed them, but I > >> dont know how much spare time they have this week. > >> > >> So, just so this doesn't drop off the bottom of the list, this SO item > >> from Miguel explains it well: > >> > >> http://stackoverflow.com/questions/5623223/no-constructor-found-for- > >> viewcontroller-ctorsystem-intptr > >> > >> I suspect that it might be a case where you need to keep a reference > >> to the object in a class-local variable, rather than a method-local > >> one or just assigning it to a (obj-c?) object. > >> > >> I've never really implemented them, tho maybe I should :). I used to > >> have the same exceptions as this, but I've not seen it in live debug > >> logs for ages - it's possible that the GC got fixed (or improved) > >> > >> Drop the list an email back if that doesn't answer your question > >> > >> Cheers > >> > >> Nic > >> > >> On Fri, Jul 27, 2012 at 8:10 PM, Adam Kemp <adam.k...@ni.com> wrote: > >> > I'm hitting a crash when receiving memory warnings in some situations. > > In > >> > one view controller (A) we are handling the memory warning by calling > >> > Dispose() on another view controller (B) which is no longer necessary. > >> > Unfortunately, something later on during the process of the (native) > >> > memory warning handling code is trying to call a method in view > > controller > >> > B, and it's trying to construct a managed object to do so. This causes > > an > >> > exception because I don't have a constructor which takes an IntPtr so > > the > >> > runtime can't construct the managed object. > >> > > >> > I know that if implementing the IntPtr constructor the crash doesn't > >> > occur. I also know that it goes away if I remove the call to Dispose, > > but > >> > I don't think that's a guaranteed fix since the object could still be > >> > GCed. I'm looking for the "right" fix, but I have several unanswered > >> > questions about what is going on that I need to find an answer to in > > order > >> > to find it. > >> > > >> > The first question is what method is being called on view controller > > B, > >> > and why is it wanting a managed object to call that method? I don't > > have > >> > an override for DidReceiveMemoryWarning or ViewDidUnload. In fact, the > >> > only override in that view controller (which inherits directly from > >> > UITableViewController) is ViewDidLoad. The exception tells me > > "Selector > >> > invoked from objective-c on a managed object (0xB9E72D0) that has been > >> > GC'ed", but it won't tell me which selector was invoked. In a simpler > > test > >> > case that I created I could only reproduce the crash if I overrode > > either > >> > DidReceiveMemoryWarning or ViewDidUnload, but in my full application I > > get > >> > the crash even though I haven't implemented either. I don't understand > >> > why. Is there a trick to figuring out which method is being invoked > > when > >> > this exception occurs? > >> > > >> > The second question is what are the rules for when we are expected to > >> > implement the IntPtr constructor for classes that inherit from > > NSObject? I > >> > don't want to blindly add it to every class, especially since in some > >> > cases it probably can't be implemented in a sane way at all (the > > Dispose > >> > method might have released resources that you can't get back without > >> > arguments from a real constructor). Is there some rule for this? Does > > my > >> > situation fit that rule? > >> > > >> > Thanks. > >> > -- > >> > Adam Kemp > >> > adam.k...@ni.com > >> > (512) 683-6058 > >> > _______________________________________________ > >> > MonoTouch mailing list > >> > MonoTouch@lists.ximian.com > >> > http://lists.ximian.com/mailman/listinfo/monotouch > >> > >> > >> > >> -- > >> Nic Wise > >> t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise > >> b. http://www.fastchicken.co.nz/ > >> > >> mobileAgent (for FreeAgent): get your accounts in your pocket. > >> http://goo.gl/IuBU > >> Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa > >> Earnest: Self-employed? Track your business expenses and income. > >> http://earnestapp.com > >> Nearest Bus: find when the next bus is coming to your stop. http:// > >> goo.gl/Vcz1p > >> London Bike App: Find the nearest Boris Bike, and get riding! > >> http://goo.gl/Icp2 > > > > > > -- > Nic Wise > t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise > b. http://www.fastchicken.co.nz/ > > mobileAgent (for FreeAgent): get your accounts in your pocket. > http://goo.gl/IuBU > Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa > Earnest: Self-employed? Track your business expenses and income. > http://earnestapp.com > Nearest Bus: find when the next bus is coming to your stop. http:// > goo.gl/Vcz1p > London Bike App: Find the nearest Boris Bike, and get riding! > http://goo.gl/Icp2 _______________________________________________ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
