10

I have tried using the leaks tool, and "analyze" etc to find the leak, but it can't find it. Using allocations I can determine the objects which are not being released.

I have noticed (by adding debugging statements in the dealloc method), that dealloc is not called for these objects.

How can I determine which objects are holding references to these objects and preventing them from being released?

xcoder
  • 967
  • 2
  • 11
  • 24
  • Objects don't "hold" references. Rather, reference counts are incremented by methods. – Hot Licks Nov 29 '11 at 13:08
  • You are right. I meant I was trying to determine which objects are not reducing the retain count when they are done with the other objects.. – xcoder Nov 30 '11 at 05:26

4 Answers4

11

If you need to see where retains, releases and autoreleases occur for an object use instruments:

Run in instruments, in Allocations set "Record reference counts" on on (you have to stop recording to set the option). Cause the picker to run, stop recording, search for there ivar (datePickerView), drill down and you will be able to see where all retains, releases and autoreleases occurred.

enter image description here

zaph
  • 111,848
  • 21
  • 189
  • 228
  • Good idea. I did that. I found it really hard to track down who was holding on to it since there were too many classes I didn't recognize, or access directly. In the end I just made a list of classes I know directly access my object, and reviewed them one by one. – xcoder Nov 30 '11 at 05:29
  • 7
    For anyone wondering, the "Record reference counts" option is hidden behind the 'i' next to 'Allocations' in the left pane http://snag.gy/F39G0.jpg – yonilevy Feb 14 '13 at 12:06
2

The analyze tool was unable to detect the problem. Using the allocations tool to capture all the reference counts was a start, but there were so many classes I didn't recognize, or access directly, I was not able to track down the problem using this method. Instead, I made a list of the classes that I was directly responsible for, and investigated each of them line by line till I found the problems. The cause was that I used some third party libraries which didn't decrement the retain count of some of my objects as expected. I guess in this case, following better software engineering principles / design patterns, and having thorough code reviews may have caught the problem earlier.

xcoder
  • 967
  • 2
  • 11
  • 24
  • 2
    Yep, ultimately careful coding practices and thorough code review are the best ways to catch most of these bugs (and many others). – Hot Licks Nov 30 '11 at 13:03
  • Yes. I believe one should use the method you mentioned BEFORE resorting to the analyze tool. It's much easier to double check your own code to ensure the issue isn't there before analyzing. – braden Dec 15 '13 at 23:58
1

I would start by building and analyzing the project ( Shift Command B in the IDE ).

John
  • 44
  • 1
1

You can overload retain/release/autorelease implementations in problematic classes (if it's an SDK class, it's possible to use a category) and set breakpoint there. Your breakpoint will be hit each time something retains your object.

Denis
  • 6,313
  • 1
  • 28
  • 27
  • This is a great solution if careful coding and review THEN analyze still don't give you an answer. – braden Dec 15 '13 at 23:58