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
