Question

This is basically related to my other question here

I’m trying to release the NSMutableArray which contains viewControllers. I do:

self.viewControllers = nil;

In viewWillDisappear because I’m moving to another view. But no matter what I do the view Controllers are not released. I also tried:

[[scrollView subviews] makeObjectsPerformSelector:@selector(removeFromSuperview)];

Where scrollview is the view owning the containing NSMutableArray.

I see the count of live view controllers (in instruments) not changing although the reference count of the containing NSMutableArray is 0.

Answer 1

A couple of observations:

1. Make sure you run your non-ARC code through the static analyzer. This can find many memory management issues that plague non-ARC code. Select “Analyze” from the “Product” menu in Xcode, or press command+shift+B. A lot of these memory management issues go away if you use ARC, but if you’re not using ARC, the static analyzer can be invaluable in examining your code.

2. Your attempt to removeFromSuperview is unnecessary, and would not affect the retainCount of the view controllers, themselves. Do I infer from this attempt, though, that you’ve created view controllers and then added their views to the scroll view? If so, did you do the necessary addChildViewController for each of those? If so, you do need to do the associated removeFromParentViewController for each of those, though.

3. The proper deallocation of the view controllers is a function of how you defined and allocated the viewControllers array, and how you populated it.

   But, for example, I have a property:

   @property (nonatomic, retain) NSMutableArray *array;
   

   And I initialized it with the following code (note the autorelease of the NSMutableArray itself (since I’m using the accessor method which will retain it for me), and the explicit release of the Object objects):

   - (void)makeArray
   {
       // create an array, using the accessor method (thus why I'm using an autorelease object)
   
       self.array = [[[NSMutableArray alloc] init] autorelease];
   
       // just add four random objects to the array.
       // note, adding them to the array increases their retain count, thus I 
       // release them to bring the retain count back to +1 ... I could have 
       // done that via autorelease, too
   
       for (NSInteger i = 1; i < 4; i++)
       {
           Object *obj = [[Object alloc] initWithString:[NSString stringWithFormat:@"Test %d", i]];
           [self.array addObject:obj];
           [obj release];
       }
   }
   

   If I examine the retainCount values, I can see that everything has a retainCount of +1, as is appropriate:

   - (void)logArray
   {
       // let's examine the retain counts for the objects in the array
       // should be "1" given there are no other strong references anywhere
   
       for (id obj in self.array)
           NSLog(@"%s %@ (retainCount = %d)", __FUNCTION__, obj, [obj retainCount]);
   
       // let's also examine the retain count for the array, itself
       // this should also be "1"
   
       NSLog(@"%s retainCount = %d", __FUNCTION__, [self.array retainCount]);
   }
   

   It (and the array’s individual objects) are properly deallocated when I clear it in the following method (a fact verified by the fact that the Object class does a NSLog during its dealloc method):

   - (void)clearArray
   {
       // let's use the accessor method to release the array and make sure
       // the pointer is nil
   
       self.array = nil;
   }
   

4. This is all a long-winded way of saying that your syntax of self.viewControllers = nil; is a perfectly suitable way to release the array (and thus its member objects), assuming the array is defined as a retain property as illustrated in the previous point. But, if the array’s member objects are not getting released, then those objects are obviously not getting their retainCount down to zero. I would try, right before your self.viewControllers = nil;, logging not only the retainCount of the array itself, but also the retainCount of the individual objects of your array, to confirm their retainCount settings.

   They should all have a retainCount of +1 at that point (otherwise there is something else retaining them, either because they’ve been over-retained, you have some retain cycle (a.k.a. strong reference cycle) in those view controllers, or something else is legitimately retaining them (e.g. at some point you pushed one of those view controllers onto the navigator stack, but you haven’t yet popped them off)).

5. If you’re still leaking, I would then use Instruments to find the leak. By the way, when examine the call tree for leaks, I find it useful to “Invert Call Tree” and to “Hide System Libraries”.

---

Update:

Above, in point 4, I warn of the risk of retain cycles. An example of a retain cycle is the use of a NSTimer by the view controller and a failure to invalidate and release the timer when it’s time to release the view controller. Chatting with you offline, this sounds like this may be the issue, where you were trying to release the NSTimer in dealloc, but the dealloc will never called because the timer, itself, is retaining the view controller. You need to manually invalidate and release the NSTimer (there by releasing the strong reference to the view controller) for any view controllers that have timers before you release the NSMutableArray. (E.g. maybe have a protocol for stopping timers, make your child view controllers conform to that.)