Trouble Finding a Memory Leak

Question

Hey everyone, i am having trouble finding a memory leak. all off my retain counts = 0 when i dealloc them but still I am flagging up a leak from the following bit of code:

- (GKSession *) peerPickerController:(GKPeerPickerController *)picker sessionForConnectionType:(GKPeerPickerConnectionType)type {
inSession = [[GKSession alloc] initWithSessionID:gameSessionID displayName:nil sessionMode:GKSessionModePeer];
printf( "insession alloc on Start: %i\n", [inSession retainCount] );
return inSession;

}

On cancelling the peer picker, so if you don't find anybody to connect to, i run this code to get rid of everything to do with the peer picker.

- (void)peerPickerControllerDidCancel:(GKPeerPickerController *)picker { 
picker.delegate = nil;
mpicker.delegate = nil;
inSession.delegate = nil;
gameSession.delegate = nil;

if(inSession != nil) {

 [self invalidateSession:inSession];
 [inSession release];
 inSession = nil;

}

[picker release];

picker = nil;
mpicker = nil;



[inSession release];


if(self.gameSession != nil) {
 [self invalidateSession:self.gameSession];
 [self.gameSession release];
 self.gameSession = nil;
}

[self.gameSession release];
self.gameLabel.hidden = NO;
self.gameState = pongStateStartGame;


[gameSession release];
[inSession release];

[inSession dealloc];
[gameSession dealloc];



[mpicker dealloc];

}

Somewhere, the code is leaking and i can't figure out for the life of me where. Any help with this would be amazingly appreciated.

Answer 1

Consider running Xcode 3.2's Build and Analyze (Under the Build menu). This can be very helpful in finding reference counting issues.

If that doesn't help, run the Leaks tool in Instruments (Run->Run With Performance Tool->Leaks).

Answer 2

Use Instruments to find your leaks.

The problem is you haven't yet understood Cocoa's memory management.

[inSession dealloc];
[gameSession dealloc];
[mpicker dealloc];

You should never have to call -dealloc yourself. NSObject calls this when the reference count reaches 0.

Try to learn the correct way to manage the memory.

Answer 3

Trying to release it a second time after setting your variable pointer to nil won't help - it won't do anything. Also don't call dealloc. While technically not against the law your

- (GKSession *) peerPickerController:(GKPeerPickerController *)picker sessionForConnectionType:(GKPeerPickerConnectionType)type

method indicates a scrappyness of style that could lead to this kind of leak. It both creates a new GKSession and sets it to an instance variable and returns a reference to it. It doesn't use either of the arguments. Either create the instance variable OR autorelease it and return it. Where is the code calling this method? Is the caller retaining the returned value?

Answer 4

In that second bit of code, you [inSession release] twice, and THEN dealloc it.

I'm sorry, but this is just about 200 different types of wrong.

Never call dealloc The system does that for you.

Don't call release on the same object twice in the same method. You never know if the object still exists after the first call. I'm surprised that you are not getting over-release exceptions, muchless a leak.

For a quick explanation of the use of retain and release, see this question.

For a more detailed explanation (and very worthwhile) read the Cocoa documentaton on the subject.

Answer 5

Just a comment about using [x retainCount] to "help" in identifying memory issues. As I learned and tried this out on several occasions - this might NOT reflect the correct situation. So do not rely on this value - don't use this - it will most probably cause confusion.

Secondly, it happens to me all the time that I use Apple code (which of course works in the example) and then "out of a blue" it causes problems in my code (showing up in LEAKS Instrument)- without having "abused it" of course. Sometimes I spend hours over hours and find the weirdest reasons for the strange behaviour. For example, just adding in UINavigationControllerDelegate as a protocol to respond to, the code might suddenly leak - without having changed any other line of code!