Question

I am using the “analyse” menu option from within Xcode 4.2 and I have three “potential leaks”. What is a “potential leak”??

When I build and run the app, everything works fine. When I use the ‘leaks’ tool, none of these three parts of code are shown to leak. So can these ‘potential leaks’ just be ignored?

The three sections of code that contain ‘potential leaks’ are (note, these are not sequential blocks of code, but are on different files)…

First…

- (void)DoDomainCheck {
AppDelegate *dataCentre = (AppDelegate *) [[UIApplication sharedApplication] delegate];
NSString *queryStringFull = [queryStringFirst stringByAppendingString:dataCentre.DomainCheckData];
labeltocheck.text = dataCentre.DomainCheckData;

responseData = [NSMutableData new];
NSURL *url = [NSURL URLWithString:@"http://www.myurl.com/whois.php"];
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:60.0];
NSData *requestData = [queryStringFull dataUsingEncoding:NSUTF8StringEncoding];

[request setHTTPMethod:@"POST"];
[request setValue:@"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" forHTTPHeaderField:@"Accept"];
[request setValue:@"application/x-www-form-urlencoded" forHTTPHeaderField:@"Content-Type"];
[request setValue:[NSString stringWithFormat:@"%d", [requestData length]] forHTTPHeaderField:@"Content-Length"];
[request setHTTPBody: requestData];
[[NSURLConnection alloc] initWithRequest:request delegate:self];
}

Second…

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
static NSString *CellIdentifier = @"Cell";

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil) {
    cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:CellIdentifier];
}

int storyIndex = [indexPath indexAtPosition: [indexPath length] - 1];
cell.textLabel.text = [[stories objectAtIndex: storyIndex] objectForKey: @"date"];
cell.detailTextLabel.text = [[stories objectAtIndex: storyIndex] objectForKey: @"title"];

[cell.textLabel setLineBreakMode:UILineBreakModeWordWrap];
[cell.textLabel setNumberOfLines:0];
[cell.textLabel sizeToFit];

cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;
return cell;
}

Third…

- (void)parser:(NSXMLParser *)parser didEndElement:(NSString *)elementName namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName {
if ([elementName isEqualToString:@"item"]) {
    [item setObject:currentImage forKey:@"media"];
    [item setObject:currentTitle forKey:@"title"];
    [item setObject:currentLink forKey:@"link"];
    [item setObject:currentSummary forKey:@"summary"];
    [item setObject:currentDate forKey:@"date"];
    [stories addObject:[item copy]];
}
}

Can anyone see any obvious issues with these sections of code, or can I just ignore these ‘potential’ leaks?

Answer 1

in Analyzer click on the arrow indicators to see the path through the code that produces the potential leak.

Part 1:
for autoreleased responseData use:

responseData = [NSMutableData data];

[[NSURLConnection alloc] initWithRequest:request delegate:self];

an NSURLConnection is allocated

Part 2:
See the answer by @Bill Bransky

Part 3:

[stories addObject:[item copy]];

The copy is not necessary, it increases the reference count and addObject also increases the reference count. When the stories object is releases a release will be sent to each of it’s items but there will still be an extra reference count from the copy.

About the copy, when writing code always know exactly why each statement and statement part is written. If in doubt research. Adding code without knowing exactly will create that “works by coincidence”, is fragile and will probably cause problems later.

It would really help you to study Apple’s memory management documents. Also strongly consider ARC.

In answer to your question, leaks don’t cause crashes but do use memory and that can be a problem.