1

I am new to Objective C, and I've read several documents both here on Stack Overflow and on Apple's web site about Automatic Reference Counting, but I still can't figure out why "Leaks" is telling me my code is leaking memory. It's probably important to note that all of this code is running on a background thread which is initiated by an NSOperationQueue.

For example, I have something like this:

NSArray *times = <receives an array of NSStrings>;
NSArray *codes = <receives an array of NSStrings>;
// these two arrays are == in length

NSMutableArray *fingerprint = [NSMutableArray array];
for (int x = 0; x < [times count]; x++) {
    long numToAdd = strtol([[codes objectAtIndex:x] cStringUsingEncoding:NSUTF8Encoding], NULL, 16);
    [fingerprint addObject:[NSNumber numberWithLong:numToAdd]];
    numToAdd = strtol([[times objectAtIndex:x] cStringUsingEncoding:NSUTF8Encoding], NULL, 16);
    [fingerprint addObject:[NSNumber numberWithLong:numToAdd]];
}

Leaks claims there is a leak on the line the allocates the array, as well as a leak on the first object add, but not the second. I have no idea why these leaks exist. Any help is appreciated.

If more code is needed, please comment and I'll be happy to provide.

Brad Larson
  • 170,088
  • 45
  • 397
  • 571
Jake Wood
  • 579
  • 1
  • 7
  • 18
  • By ARC standards, your code is fine. `[NSMutableArray array]` and `[NSNumber NSNumberWithLong:]` both generate autoreleased objects, so even if you weren't using ARC your code is not leaking any memory. I'd clean the project and double-check that the leaks are still present. If they're still there, write it off as a false positive. – mopsled Jun 24 '12 at 01:27
  • 2
    Note that Instruments tells you where a leaked object was allocated (because that helps you understand which object it is), but that doesn't mean the leak is at or near the allocation. The leak may be caused in some other code which over-retains or under-releases the object. You have to review the history of a specific leaked object (click the circled-arrow button next to an address) to see where a release was not balanced by a retain. – Ken Thomases Jun 24 '12 at 01:58
  • As it turns out, it wasn't related to allocation at all. This snippet of code belongs to a method in a class, and that class had an `NSString` property I'd created called `release` (to represent the "release" of a song). I'm guessing this conflicted with the standard `release` call for memory management purposes. In any case, it's all fixed now, though I'm not sure why the compiler/ARC allows you to declare properties called "release" when it breaks ARC. Thanks for your input! – Jake Wood Jun 24 '12 at 05:12
  • 1
    @JakeWood: You're free to override built-in methods all you want. The compiler cannot rightfully disallow you from creating a property called `release` if you really want to do that. Note that you could work around this by leaving the property as `release` but overriding its getter method, e.g. `@property (strong, getter=songRelease) NSString *release`. – Lily Ballard Jun 25 '12 at 21:43
  • See this reply to a similar question: http://stackoverflow.com/a/9880946/1791355 In short "Cocoa creates an autorelease pool for you on the main thread, but doesn't do anything for you on background threads" – PabloR Jan 08 '13 at 16:19

0 Answers0