NSDecimalNumber leaks memory if not used with AutoRelease pool?

Question

NSString* str = [[NSString alloc] initWithString:@"0.05"];
NSDecimalNumber* num = [[NSDecimalNumber alloc] initWithString:str];
NSLog(@" %@", num);
[str release];
[num release];

leaks memory

*** __NSAutoreleaseNoPool(): Object 0x707990 of class NSCFString autoreleased with no pool in place - just leaking

Can someone suggest a workaround ?

Answer 1

Wrap your use of the class in an NSAutoreleasePool.

Answer 2

Internally NSDecimalNumber appears to use autoreleased NSString objects. So you need to have an autorelease pool in place to catch these.

Answer 3

What others said; wrap your code with an NSAutoreleasePool. An NSAutoreleasePool is actually surprisingly efficient; will incur very little overhead. You don't want to, say, surround every few lines of code with one, but it is unlikely that they'll be measurable in normal use.

Do not try to use Foundation without Autorelease Pools

Down that path lies madness. Don't bother. Sure -- it is sometimes a good idea to put some effort into minimizing use of pools, but there will be many cases -- like this one -- where they are unavoidable.

No, really, I'm not kidding:

Cocoa always expects there to be an autorelease pool available. If a pool is not available, autoreleased objects do not get released and you leak memory. If you send an autorelease message when a pool is not available, Cocoa logs a suitable error message.

---

I have C++ communication library written many years ago. It calls back every time there is network event (sometimes in a newly created thread). Your advise had disastrous effect on the performance of my application.

My answer wasn't advice, it was a very specific description of the exact rules by which the Cocoa frameworks are implemented. That your code worked before was by coincidence. While there is certainly a behavior change, it isn't a regression for code that is following the rules.

Arbitrary threading like that is exceedingly risky within Cocoa (well, really, anywhere). I've done such integrations a number of times and have generally found the best solution to be to handle the events in one or more queue like mechanisms, depending on concurrency needs. The queues can then take care of periodically dealing with autorelease pools.

Of course, the truly arbitrary threading you describe would need some mechanism to move the data over to the queue's thread(s)....

Answer 4

You haven't told us anything about the context in which this code runs. In an ordinary Cocoa or Carbon app where you're running code in response to events, autorelease pools are set up automatically.