How to tell if object is in an NSAutoreleasePool

Question

I would like to know how many times an object has been autoreleased. I've used objective c long enough that it's generally straight forward to know whether an object has been autoreleased or not, however I constantly see questions dealing with memory and retain counts. At some point an answer always ends, "You can't trust the retainCount of an object" - which I agree with, BUT if you could determine how many times an object has been autoreleased, then you actually could trust the retainCount if you added a category like:

@interface NSObject (NSObject_MemoryDebugging)
- (NSUInteger) autoReleaseCount;
- (NSUInteger) retainCountWithAutoRelease;
@end

@implementation]
/** Determine how many times this object has been marked for autorelease **/
- (NSUInteger) autoReleaseCount;
{
   // ??? not sure how to figure this out.
   return 0;
}

 - (NSUInteger) retainCountWithAutoRelease
{
   NSUInteger retainCount = [self retainCount];
   NSUInteger autoReleaseCount = [self getAutoReleaseCount];  // ???
   return retainCount - autoReleaseCount;
}
@end

There would still be an exception for immutable types as those typically increase the retain count during a copy, so you still can't trust retainCount on those.

What I am NOT proposing

I am not seeking this answer to use retainCount in production code. However, I can see this as being valuable for someone debugging memory issues.

I imagine some people will HATE this question since programmers should not care about how many times an object has been autoreleased. Coding should be all about balancing allocs, retain, copy, new with release, end of story. However, the point of this is to help out people banging their heads. [NSObject retainCount] burns a lot of people, and an answer to this question would be pretty cool.

I'm certain there's a way to determine how many times an object has been autoreleased. I just don't know what it is, hence the question.

See similar question: Objects inside NSAutoreleasePool in objective-c.

Edit

---

Thank you everyone for your answers. You may find this interesting => Ariel pointed out that GNUStep's implementation of Cocoa and specifically it's NSAutoReleasePool has this method: +(NSUInteger)autoreleaseCountForObject:(id)anObject. This method is slow, and only returns the autorelease count from NSAutoReleasePools on the callers thread. Still... It's interesting that its there. The docs cite that it is really only useful for debugging. This is really what I was hoping to find (or find possible) in the Cocoa framework somehow.

I agree with the answers given that even if it were possible to get the autorelease count that better tools exist (Zombies, Leaks, static analyzer).

Nieshanieto

Apple is pushing autorelease into the language/compiler and any attempt to get at this information will have a short lifetime - Search for Automatic Reference Counting to find out details. – Baronetcy

turn on NSZombies and you can always reference any object that was created - if it's a zombie, you know it's been released to 0 – Baronetcy

You say, "I can see this as being valuable for someone debugging memory issues." Can you give a specific example of an issue where knowing the autorelease count of an object was the best way to solve a problem? I've been trying to think of one and I can't. – Lilliamlillian

A valid and interesting question. Ultimately, though, the answer is still "don't bother, there are much better tools". In particular, the claim that "...you actually could trust the retainCount..." is incorrect without fully accounting for threading. As well, there are classes in the frameworks that directly modify their retain counts w/o invoking methods and other classes that work in conjunction with the autorelease pool without themselves being autoreleased. – Putnam

Answer 1

First, you'd have to deal with multiple autorelease pools and an object being autoreleased more than once, possibly in multiple pools.

Second, it's not (just) NSAutoreleasePool that's making -retainCount untrustworthy. The problem is that all sorts of objects, both yours and Apple's, retain things for all sorts of reasons, most unbeknownst to you. Even accounting for autorelease, your objects will often not have the retain count you expect, because behind the scenes, something's observing it or placing it in a dictionary temporarily, etc.

The best ways to debug memory issues are the Leaks instrument, NSZombie, and the static analyzer.

Orangeism

Is there anywhere I can learn more about what else makes retainCount untrustworthy, b/c I thought autorelease was the only thing making it untrustworthy. I'm aware of CFRetain and CFRelease, but I didn't think those threw the retainCount off. I haven't tried that yet either. Also, apparently it is possible to list out all objects in autorelease pools (see my answer below). I imagine there's a way to directly query NSAutoreleasePools for the count of an object, but that implementation detail is hidden pretty well. – Nieshanieto

Apple mentions it right in the documentation for -retainCount. Besides autorelease, they also mention "This method is typically of no value in debugging memory management issues. Because any number of framework objects may have retained an object in order to hold references to it..." That's the problem: so much of Objective-C uses the Cocoa framework, and you have no idea what Cocoa is going to do to your objects, let alone its, in terms of retain/release. It's not that -retainCount is inaccurate, it's that the accurate value it gives is worthless because we can't understand why. – Orangeism

Answer 2

No, there isn’t a public API to determine whether an object has been autoreleased.

Even if this were publicly available, your -retainCountWithAutoRelease method would have some problems:

• An object can be placed multiple times in the same autorelease pool so you’d need an autorelease count for a single autorelease pool instead of a flag indicating whether an object has been autoreleased;

• An object can be placed in multiple autorelease pools due to multithreading, so you’d need an autorelease count spanning multiple autorelease pools;

• Due to multithreading, you’d need to synchronise your code with Cocoa’s handling of retain counts and autorelease pools, and the internal locking used by Cocoa is not visible to applications.

Opprobrium

Looks like GNUStep's implementation of NSAutoReleasePool has +(NSUInteger)autoreleaseCountForObject:(id)anObject. See GNUStep NSAutoReleasePool docs if you are interested. It has the problems you mention. It's slow and only counts autoreleases from NSAutoReleasePools in the current thread. Still... interesting that they offer it. Ariel pointed me to look at the GNUStep docs in his answer. – Nieshanieto

Answer 3

NSAutoreleasePool does have an +(void)showPools method that I was previously completely unaware of. This could be useful. Also see Is there a way to inspect an NSAutoreleasePool's objects?. On that thread, KennyTM said (in a comment):

Well, since the content is printed to stderr, you could reopen the stream and parse from it to get all the pointers

For reference, I used class-dump against the Foundation framework to see it's NSAutoreleasePool details and it had the following:

@interface NSAutoreleasePool : NSObject {
    void *_token;
    void *_reserved3;
    void *_reserved2;
    void *_reserved;
}

+ (void)addObject:(id)arg1;
+ (id)allocWithZone:(struct _NSZone *)arg1;
+ (void)showPools;
+ (void)releaseAllPools;
+ (unsigned int)autoreleasedObjectCount;
+ (unsigned int)topAutoreleasePoolCount;
+ (BOOL)autoreleasePoolExists;
+ (void)enableRelease:(BOOL)arg1;
+ (void)enableFreedObjectCheck:(BOOL)arg1;
+ (unsigned int)poolCountHighWaterMark;
+ (void)setPoolCountHighWaterMark:(unsigned int)arg1;
+ (unsigned int)poolCountHighWaterResolution;
+ (void)setPoolCountHighWaterResolution:(unsigned int)arg1;
+ (unsigned int)totalAutoreleasedObjects;
+ (void)resetTotalAutoreleasedObjects;
- (id)init;
- (void)drain;
- (oneway void)release;
- (id)initWithCapacity:(unsigned int)arg1;
- (void)addObject:(id)arg1;
- (id)retain;
- (unsigned int)retainCount;
- (id)autorelease;
- (void)dealloc;
@end

I've added this as an answer as it seemed more of an answer than more detail on the question I asked.

Nieshanieto

Answer 4

Sounds like you'll need to override -(id)autorelease; method as the work of adding object to NSAutoreleasePool done there.
Something like that:

-(id)autorelease{
    _isAutoreleased = YES;  //some BOOL member initialized to NO and returned on -(BOOL)isAutoreleased;
    [NSAutoreleasePool  addObject:self];
    return self;
}

Also take a look at this link

Lillianalillie

I see that you have linked to the GNUStep docs. GNUStep might not do things the same way as Cocoa. If you want to override autorelease, returning [super autorelease] seems a much safer plan. – Inquiring

@Lillianalillie +1 That is really interesting that GNUStep has a method +autoreleaseCountForObject:(id)anObject. The docs on that specifically say that it is slow, only returns the count of nsautorelease pools on the current thread, and is primarily useful for debugging. I'm certain something like this could easily exist in the Cocoa NSAutoReleasePool. – Nieshanieto

@JoshCaswell unfortunately you cannot get what you want by calling super, as we are talking about category expansion of the class rather then overriding one... The only thing that I've forgot thought, is to release self as it should be done after calling +(void)addObject:(NSObject)object; class method of the NSAutoreleasePool class – Lillianalillie

@Lillianalillie You can use method swizzling to call into the base class's method that you've overridden (like autorelease in this instance). I tried overriding autorelease and it actually worked surprisingly well. I didn't exhaustively test it, and to get it to work I used a static NSMutableDictionary where the object was the key and the value was an NSNumber containing the autorelease count. However this adds a retain count to the object added in the dictionary, which ends up being problematic. Good idea though! – Nieshanieto

Subclasses inherit protocols just as well as other methods; you most certainly can call the superclass's implementation using [super overriddenProtocolMethod]. – Inquiring

Swizzling will do the work much more safe, you are right. Still, you'll found yourself calling self, not super... :) – Lillianalillie

Why was this answer voted down? Anyone? I thought it was useful information. Not necessarily the answer, but still useful. – Nieshanieto