views:

34

answers:

1

I've gone thru my app using build/analyze and been able to resolve all issues.

but running under leak tool it detects a leak and says it comes from tvc:viewDidLoad where tvc is a tableViewController

it further references NSArray -> sectionlist

it shows a malloc refct=1 then a retain refct=2 then a release refct=1

here is viewDidLoad below followed by the dealloc and the header

I don't see where this is a problem? Am I missing something?

other than the code I've included, the sectionList is only referenced in 2 other places -

  1. in numberOfRowsInSection

    return [[self sectionList] count];

  2. in cellForRowAtIndexPath

    [[cell textLabel] setText:[[self sectionList] objectAtIndex:indexPath.row]];

is this a red herring? ie; is it a real leak or is the leak tool only capable of showing the alloc but then not showing where the release happens in the dealloc when the tvc is unloaded later?

enter code here

/// code 
////////////////////////

// property
@synthesize sectionList = ivSectionList;

/*
*********************************************
build list of sections
*********************************************
*/
- (void)viewDidLoad
{
[super viewDidLoad];  

// alloc a local array and init with values  
NSArray *sections = [[NSArray alloc] initWithObjects:@"A", @"B", @"C", nil];

// assign local array to tvc ivar  
[self setSectionList:sections];

// release local array  
[sections release], sections=nil;
}


/*
*********************************************
release ivSectionList
*********************************************
*/
- (void)dealloc
{
[ivsectionList release], ivsectionList=nil;
[super dealloc];
}


//////// header
////////////////////////////////////////
#import <UIKit/UIKit.h>

@interface tvc : UITableViewController
{
NSArray *ivsectionList;
}

@property (nonatomic, retain) NSArray *sectionList;
@end
//////////////////////////////////////// 
A: 

leaks (or Instruments) is telling you where the leaked object is created.

most likely, a client is not releasing it.

a subclass may also be misusing this class, it's a good idea to make your ivars @private by default.

alternatively, you may want to try atomic read/write, just in case you're having a threading issue in this case.

(but yes, the excerpt looks correct)

Justin
using activity monitor I see an add memory, release pattern as I work my way up and down the path to and from this tvc - 15.13 - 15.23 - 16.42 - 15.28 - 15.14 repeatably - seeming to indicate that there really isn't a leak. but I do blow up after a bunch of operations so it might be telling the truth. will investigate further and post results later. thanks
Mike Stenzler
This was a legitimate leak - took a while but I found it. The leak was elsewhere - an instance of this class was created and not released. The crashes were un-related.
Mike Stenzler
cool. thanks for the follow up. there are occasionally leaks in the system frameworks, but that is less common.
Justin