Hi Rolf,
Indeed, I never remove these objects from their parent view. Therefore, I repeated this process for its parent, and found the same thing. So I continued all the way up the tree until I got to the UIViewController: http://i.imgur.com/hRgzZ.png It certainly feels like we're getting closer to the root cause, but unfortunately I'm still not able to see why the UIViewController is not getting collected. This gets pushed onto my UINavigationController and then later popped off, yet for some reason the retain count is still 1 at the end. I fired up the mono profiler again but it just shows <Other Root> under the UIViewController. I tried manually calling .Dispose() on it after I popped it off of the navigation controller. Unfortunately after disposing it MonoTouch throws this error: System.Exception: Selector invoked from objective-c on a managed object of type WAML.Controls.Screen+MyUIViewControler (0x886DF30) that has been GC'ed ---> System.MissingMethodException: No constructor found for WAML.Controls.Screen+MyUIViewControler::.ctor(System.IntPtr) at System.Activator.CreateInstance (System.Type type, BindingFlags bindingAttr, System.Reflection.Binder binder, System.Object[] args, System.Globalization.CultureInfo culture, System.Object[] activationAttributes) [0x00174] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System/Activator.cs:299 at System.Activator.CreateInstance (System.Type type, System.Object[] args, System.Object[] activationAttributes) [0x00000] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System/Activator.cs:234 at System.Activator.CreateInstance (System.Type type, System.Object[] args) [0x00000] in <filename unknown>:0 at MonoTouch.ObjCRuntime.Runtime.ConstructNSObject (IntPtr ptr, IntPtr klass) [0x0000d] in /Developer/MonoTouch/Source/monotouch/src/ObjCRuntime/Runtime.cs:210 --- End of inner exception stack trace --- at MonoTouch.ObjCRuntime.Runtime.ConstructNSObject (IntPtr ptr, IntPtr klass) [0x00045] in /Developer/MonoTouch/Source/monotouch/src/ObjCRuntime/Runtime.cs:215 at MonoTouch.ObjCRuntime.Runtime.GetNSObject (IntPtr ptr) [0x0001f] in /Developer/MonoTouch/Source/monotouch/src/ObjCRuntime/Runtime.cs:259 at MonoTouch.ObjCRuntime.Runtime.GetNSObjectWrapped (IntPtr ptr) [0x00000] in /Developer/MonoTouch/Source/monotouch/src/ObjCRuntime/Runtime.cs:276 at (wrapper native-to-managed) MonoTouch.ObjCRuntime.Runtime:GetNSObjectWrapped (intptr) at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x0004c] in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:38 at WamlEntryPoint.Main (System.String[] args) [0x00000] in /Users/user/Desktop/WarLight/Project/WamlEntryPoint.cs:35 Does this mean something in MonoTouch is still referencing it? Where can I go from here? Thanks! From: Rolf Bjarne Kvinge [mailto:[email protected]] Sent: Wednesday, October 31, 2012 5:29 AM To: Randy Ficker Cc: [email protected] Subject: Re: [MonoTouch] Understanding the memory profiler Hi, On Wed, Oct 31, 2012 at 12:29 PM, Randy Ficker <[email protected]> wrote: Hey Rolf, Okay, I enabled reference counting as you showed and examined an object that I'm 100% sure should have been released: http://i.imgur.com/qdj4v.png I see monotouch_retain_trampoline doing 4 retains and 2 releases. Here's the full stacktraces from all events: http://pastebin.com/jmYzQWHn The first two retains have identical stack traces. I can tell from the stack trace that these are both happening when I insert the UIView into the visual tree (I'm just passing it to InsertSubview) The third and fourth retains are getting released immediately after they're taken with an almost identical stack trace. So I believe the big question is: why aren't the first two retains getting released? I'm gathering that MonoTouch calls retain when a view is added to the visual tree (twice?). Under normal operation, when would the corresponding releases get called, and do you have any idea why this might not be happening here? This is a bit confusing, but the fact that monotouch_retain_trampoline shows up in the stack trace does not mean that MonoTouch (or your code) directly called retain - we override the retain selectors for all objects so monotouch_retain_trampoline will show up in every retain stack trace. You have to look a little bit further down to see exactly who is retaining your object. In fact it is iOS who calls retain when you insert the objects into the visual tree: 2 iosWarLight monotouch_retain_trampoline /Developer/MonoTouch/Source/monotouch/libmonotouch/monotouch-glue.m:1179 3 UIKit -[UIView(Internal) _addSubview:positioned:relativeTo:] 4 UIKit -[UIView(Hierarchy) insertSubview:atIndex:] Do you ever remove those objects from the container they're added to? If you don't, but believe the container should be freed (and thus automatically release those inserted objects), you need to do the same procedure for the container to see why that object isn't freed. Rolf
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
