How to check the retain count while debugging

Question

Does anybody know how can I check the retain count of an object while in debug mode? I have tried to add an expression [objInstance retainCount] but it did not work. I have also tried the print object PO [objInstance retainCount] in the console but again it did not work.

Argue

Check this descriptive post out This answer was provided at the beginning of this year, but has a detailed description of why NOT to use retain count – Shoop

Do not ever use retainCount! If you ever want to check memory leak use xcode memory leak tools instead – Faunia

What do you mean here by "did not work?" – Nova

By "did not work" i meant that expressions did not give me the retain count. It displayed [objInstance retainCount] = (<unknown type>) <unknown type> – Argue

Thanks James Webster for the reference – Argue

I was not using it for leaks. I wanted to track the retain count of an particular object in between 2 methods. But yes for memory leaks the Leaks tool is good and I have also found Zombies very useful. – Argue

Have you tried: (lldb) po (int)[0x10a074000 retainCount] 2 – Cockadoodledoo

Answer 1

I am guessing you are talking about getting the retainCount in GDB?

You can use the retainCount method.

This is how I get in my Code.

(gdb) p (int)[product retainCount]
$2 = 4

Hope this is what you are looking for.

Birdiebirdlike

Yes .. in fact with the (int) casting it even worked in the debugging expression. thanks! – Argue

Answer 2

You can print this with

NSLog(@"Retain count might be %d",[objInstance retainCount]);

However, this number isn't reliable due to things like autorelease. You should rather read up on memory management and make sure that your retain and release calls match up. You can also run Build/Build and Analyze to get Xcode to help you find possible memory leaks, but again, these are only potential leaks. You'll need to check each one yourself to be sure.

Fossick

Calling -retainCount Considered Harmful is a good read. – Impudence

Yes, ever use retainCount, it's value is not guaranteed to be meaningful. – Yepez

Thanks @Bavarious for the reference it's very informative. I am aware of the autorelease pools, however I am safe since no? Since I have only one autorelease pool which is the application's default, therefore they will only be autoreleased at the end of the application. – Argue

@mrd Not really. Cocoa creates an autorelease pool at the beginning of each event loop and drains it at the end of each event loop; see the documentation. And the main problem is that it’s hard to be sure when an object has been autoreleased or not, and that influences its retain count. – Impudence

@Bavarious thanks. I have read the doc however now I got confused of when do event loops get created and destroyed (i.e. when are autorelease queues created and drained) I read that these happen on tap event for example, does this also happen when a new view is loaded such as when a modal viewcontroller is presented and dismissed, and when viewcontrollers are pushed/popped onto/out of the navigation stack? – Argue

@mrd You can think of events as being user-initiated or system-fired. Let’s say your application has finished launching. Cocoa creates an event loop + autorelease pool and waits for something to happen. If the users taps a button, the corresponding action is sent and, for example, your code pushes a new view controller. This is still the same event loop. After all your methods finish executing, the event loop reaches its end and the corresponding autorelease pool is drained; a new loop starts and a new autorelease pool is created. – Impudence

@mrd You might want to read the Cocoa Event-Handling Guide. – Impudence