0

When i run profile with this code in Instruments, I got 35 memory leaks of Player. How i need to handle to avoid memory leaks?

NSMutableArray *players = [NSMutableArray array];
NSData *data = [theRequest responseData];
NSArray *array = (NSArray *) [decoder objectWithData:data];
int len = 35;
for (int i = 0; i < len; i++) {
    NSDictionary *dic = (NSDictionary *) [array objectAtIndex:i];

    Player *p = [[Player alloc] init];
    p.playerID = [dic objectForKey:@"id"];
    p.name = [dic objectForKey:@"name"];
    p.country = [dic objectForKey:@"country"];
    p.club = [dic objectForKey:@"club"];
    p.imageURL = [dic objectForKey:@"image"];
    p.likeNumber = [dic objectForKey:@"like_number"];
    p.likeTime = [dic objectForKey:@"like_time"];
    p.likePlayerID = [dic objectForKey:@"like_player_id"];
    p.likeDeviceID = [dic objectForKey:@"like_device_id"];
    p.disLikeNumber = [dic objectForKey:@"dislike_number"];
    p.disLikeTime = [dic objectForKey:@"dislike_time"];
    p.disLikePlayerID = [dic objectForKey:@"dislike_player_id"];
    p.disLikeDeviceID = [dic objectForKey:@"dislike_device_id"];

    [players insertObject:p atIndex:i];
    [p release];
}
Nafiz
  • 462
  • 4
  • 17

4 Answers4

4

The code shown above is correct. The leaks are likely coming from something else that is retaining and not releasing a Player object.

Note that the Leaks instrument only shows where the leaked object was allocated, not where the incorrect memory management occurred. However, if you click the little gray arrow next to one of the leaked objects, you can actually see the entire retain/release history of the object. You should be able to examine that and figure out where the unbalanced retain came from. You may find the static analyzer (Product -> Analyze) more useful in tracking down the incorrect memory usage.

BJ Homer
  • 48,806
  • 11
  • 116
  • 129
  • Thanks BJ, Let me try again with your comment. – Nafiz Nov 22 '11 at 18:07
  • When I analyze that code static analyzer does not count that as a memory leaks. PlayerService.m is the only place where Player class is being used. Above block of code is in PlayerService.m. – Nafiz Nov 22 '11 at 18:28
  • 1
    Realize that if you leak the array you're putting the `Player` objects in, the Players will leak as well. Did the static analyzer find any other issues? – BJ Homer Nov 22 '11 at 18:46
  • No it did not find any other issues. – Nafiz Nov 23 '11 at 02:15
  • Given that there are 35 instanced of this object being leaked, I think it's pretty clear that the `players` array is being leaked at some point, in turn leaking 35 instances of the Player class. Examine that array's usage very carefully, as well as classes that have this array as an instance variable. – Brad Larson Nov 24 '11 at 19:13
1

Perhaps it thinks your players pointer is being lost at the end of the code block.

Or perhaps it is getting confused over the status of the array.

Does it complain if you create the mutable array with alloc-init instead of array: ? (Using 'array' without a retain does leave the whole thing on the allocation pool.)

Walt Sellers
  • 3,806
  • 30
  • 35
  • Yes it does complain too with alloc-init. – Nafiz Nov 22 '11 at 18:20
  • 2
    When the array is released, it will itself send `release` to all the objects it contains. The array not being retained wouldn't cause a leak. – jscs Nov 22 '11 at 20:02
  • Thanks Josh I didn't know array send release to all the objects it contains. – Nafiz Nov 23 '11 at 02:01
0

I assume its something in your player class. Make sure you are releasing all of its properties.

Matt G
  • 350
  • 3
  • 10
0

Port your project to ARC (Automatic reference counting). You won't need to deal with releasing and retaining anymore.

Faser
  • 1,256
  • 1
  • 18
  • 36
  • Actually I'm using a library which does not work when ARC enabled. – Nafiz Nov 22 '11 at 17:45
  • 3
    For that matter, not everything can be solved by simply "porting to ARC". – BoltClock Nov 22 '11 at 18:05
  • What do you mean by that, @BoltClock ? – Faser Nov 22 '11 at 21:14
  • 2
    To put it simply, converting a project to ARC is a lot of work (for Xcode, anyway). For big projects, making such a huge change is not very assuring - a lot of tests have to be done to ensure an app will still work correctly even with ARC enabled, as it doesn't solve *all* memory management problems - just reference counting headaches. Some other issues to watch out for are described in [this question](http://stackoverflow.com/questions/6260256/what-kind-of-leaks-does-objective-cs-automatic-reference-counting-in-xcode-4-2). – BoltClock Nov 22 '11 at 21:33