2

I'm having this issue for some time and tried several ways to avoid it but now i've decided to fix it once and for all :)

I have a chat view controller which observe an NSSet with KVO, the ChatVC has a UITableView and every time a new ChatMessage being inserted to the NSSet, it's being added also as a UITableViewCell to the tableview.

Now, my issue is not with the observation, it's somehow related to memory management I guess. in my ChatVC the method dealloc never get called so that vc is always in the background observing that NSSet object.

I've tried manually remove the observer on viewWillDisappear but the ChatVC is still in the background.

Profiling it with Instruments showed me that actually it's coming from the pushViewController that lead to that ChatVC:

MZChatViewController* chatViewController = [[MZChatViewController alloc] initWithNibName:@"MZChatViewController" bundle:nil];
chatViewController.shouldShowIndetermineConnectingIndicator = showIndicator;

// instruments shows 100% on this row
[self.navigationController pushViewController:chatViewController animated:animated];

chatViewController = nil;

A little search here and google gave me actually nothing helpful, I've passed through all my code in that VC and really made an effort to find a retained cycle that can also cause this no deallocation problem and found nothing.

PS. Xcode 5, iOS 7 SDK, ARC

Solved: Apparently it was nothing to do with pushViewController:animated: method, Instruments just marked this spot as the cause for the retained cycle because it was firing an NSTimer which was running at viewDidLoad. So invalidating that timer in viewWillDisappear solved it.

Ariel
  • 143
  • 10
  • Did you try the Leaks instrument? - Did you try the Analyzer? – matt Feb 01 '14 at 18:26
  • Yea, I wrote it... I got that [self.navigationController pushViewController:chatViewController animated:animated]; got 100% using Instruments Leaks tool – Ariel Feb 01 '14 at 18:27
  • I don't know what "100% using Instruments Leaks too" means. If you've got a leak, you've got a retain cycle. – matt Feb 01 '14 at 18:29
  • Yes, I know. If instruments marked some method I wrote, maybe I had a clue what can cause that cycle. But it marks "pushViewController", so I have nothing to do with it. – Ariel Feb 01 '14 at 18:31
  • Are you sure the retain cycle isn't caused by something else? For example, using NSNotificationCenter with an observer object and a block can do this. – matt Feb 01 '14 at 18:31
  • All of my NSNotificationCenter observations are removed on viewWillDisappear. do I need something else to release them? – Ariel Feb 01 '14 at 18:51
  • Are you using observers and blocks? Does the block mention self? Are you retaining the observer object? Then the observer is retaining self and you have a retain cycle. – matt Feb 01 '14 at 18:54
  • 1
    No, in the only block I'm using I use a __weak reference inside. – Ariel Feb 01 '14 at 18:57
  • 1
    Humor me. If you are retaining your observer object (as an instance variable), release it (by setting that instance variable to nil) in `viewWillDisappear` after you remove the observation, and see if that solves the problem. – matt Feb 01 '14 at 19:05
  • 1
    Actualy I found (I think) the main cause. I'm setting an property overriding the default setter, (of course first doing _object = object). when I'm commenting this line the VC is deallocating. This property is nonatomic strong, so I don't know why it cancels the deallocation :/ – Ariel Feb 01 '14 at 19:35
  • 1
    ***FIXED!*** It was an NSTimer that I forgot to invalidate on viewWillDisappear... THANK YOU! – Ariel Feb 01 '14 at 19:46
  • 2
    Yes, see the discussion of NSTimer and retain cycles in my book: http://www.apeth.com/iOSBook/ch12.html#_unusual_memory_management_situations (towards the end of that section) – matt Feb 01 '14 at 20:55

1 Answers1

1

Although this wasn't the problem here, perhaps this will help someone else who runs into a similar issue with deallocating UIViewControllers.

Our UIViewController wasn't deallocated because a custom delegate property held a strong reference.

Crashalot
  • 33,605
  • 61
  • 269
  • 439