Hello Adam, Thanks for the bug report / test case. We're quite busy this week (xummit) but will be looking into this asap.
The general case is well explained by Miguel's answer on stackoverflow. Many times this occurs with UIKit (e.g. for View[Did|Will]Unload) because a parent (on the native side) holds a reference for longer than anticipated (i.e. it does not look like it should be needed anymore, but it is retained natively and can, in some cases, call back to managed code). Your description does not match this exactly so there might be a bug. Sadly it is, right now (and we're working on fixing this), difficult to diagnose such issues (trial and error) since the managed stack trace does not include why the object instance is needed. Until this is fixed the best thing is provide us a test case so we can dig into it. Regards, Sebastien On Tue, Jul 31, 2012 at 11:29 AM, Adam Kemp <[email protected]> wrote: > 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 > [email protected] > (512) 683-6058 > > Nic Wise <[email protected]> wrote on 07/30/2012 04:05:54 PM: > >> From: Nic Wise <[email protected]> >> To: Adam Kemp <[email protected]> >> Cc: [email protected], Rolf Bjarne Kvinge >> <[email protected]>, Sebastien Pouliot <[email protected]> >> 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 <[email protected]> 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 >> > [email protected] >> > (512) 683-6058 >> > >> > Nic Wise <[email protected]> wrote on 07/30/2012 01:01:26 PM: >> > >> >> From: Nic Wise <[email protected]> >> >> To: Adam Kemp <[email protected]> >> >> Cc: [email protected], Sebastien Pouliot >> >> <[email protected]>, Rolf Bjarne Kvinge <[email protected]> >> >> 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 <[email protected]> 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 >> >> > [email protected] >> >> > (512) 683-6058 >> >> > _______________________________________________ >> >> > MonoTouch mailing list >> >> > [email protected] >> >> > 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 [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
