And one more note (I also added this to the bug report). I added all kinds of overrides to CrashingViewController() and also added the IntPtr constructor. Then I put breakpoints in the ctor and all overrides.
I can see the following happening: After the object has been disposed... * CrashingViewController.ClassHandle gets called * the IntPtr ctor gets called at some point. * Then the breakpoint in CrashingViewConrtroller.DidReceiveMemoryWarning() is hit (coming from UIApplication.Main) * Next CrashingViewController.Dispose(false) is triggered (Stacktrace shows it is coming from NSObject.Finalize) In rare cases I'm getting this output: at (wrapper managed-to-native) MonoTouch.ObjCRuntime.Messaging.IntPtr_objc_msgSendSuper (intptr,intptr) <IL 0x00026, 0xffffffff> at MonoTouch.Foundation.NSObject.get_Description () [0x00021] in /Developer/MonoTouch/Source/monotouch/src/Foundation/NSObject.g.cs:538 at MonoTouch.Foundation.NSObject.ToString () [0x00000] in /Developer/MonoTouch/Source/monotouch/src/shared/Foundation/NSObject2.cs:126 at (wrapper runtime-invoke) <Module>.runtime_invoke_object__this__ (object,intptr,intptr,intptr) <IL 0x00050, 0xffffffff> at MemoryWarningTest.CrashingViewController.get_ClassHandle () [0x00000] in /Users/rene/Downloads/MemoryWarningTest/MemoryWarningTest/CrashingViewController.cs:59 René Am 31.07.2012 um 17:47 schrieb Sebastien Pouliot <[email protected]>: > 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
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
