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 _______________________________________________ MonoTouch mailing list MonoTouch@lists.ximian.com http://lists.ximian.com/mailman/listinfo/monotouch
