views:

294

answers:

5

This code is leaking, the performance tool blames two leaks on this block of code. If i comment it out the leak doesn't happen. Any help pinning it down would be greatly appreciated.

Leaks:

Malloc 48 bytes

NSCFarray 32 bytes

Code Block:

    NSArray *myArray = [[NSArray alloc] initWithObjects: @"Add", @"Edit", nil];
    segmentControl = [[UISegmentedControl alloc] initWithItems:myArray];
    [myArray release];
    [segmentControl setSegmentedControlStyle:UISegmentedControlStyleBar];
    [segmentControl setMomentary:YES];
    [segmentControl addTarget:self action:@selector(addOrEditPressed) forControlEvents:UIControlEventValueChanged];
    UIBarButtonItem *myBarButtonItem = [[UIBarButtonItem alloc] initWithCustomView:segmentControl];
    self.navigationItem.rightBarButtonItem = myBarButtonItem;
    [myBarButtonItem release];
+1  A: 

Is segmentControl meant to be released?

taspeotis
I wonder is that Malloc 48 leak actually a UISegmentedControl 48 leak that's just being misreported by Cocoa? I agree with taspeotis that you should consider whether to release segmentControl at the end...
martinr
A: 

myArray's retain count is still one after this section of code. When you add it to the initWithItems to create the segmentControl, it now has a reference to the object.

Is that possibly the leak?

Mr-sk
He's releasing myArray after that though, so there shouldn't be a leak.
Nimrod
+1  A: 

As long as segmentControl is nil when you enter the code block and is being released somewhere else in your code (like dealloc or viewDidUnload) then you are doing nothing wrong.

Have you tried running your code under the static analyzer (Xcode menu: Build | Build & Analyze)?

Instruments can sometimes generate false positives when searching for leaks. If the leaked memory doesn't accumulate over time, your worst case scenario is that your program is leaking a total of 80 bytes. Leaks that grow over time are what you should be concerned about.

benzado
Unfortunately I have the growing over time type, every time I load this view it seems to leak the memory.
Alex Gosselin
Static analyzer didn't point out the leak, good tool though. I still am accumulating memory somehow from this code. Is there any way for segmentControl, an instance variable, to have a value other than nil when viewDidLoad is called? assuming I haven't overridden initWithNibName:bundle:
Alex Gosselin
If that code is in your viewDidLoad method, you should be releasing segmentControl and setting it to nil in viewDidUnload. However, viewDidUnload is only likely to be called due to a memory warning. When you say you are repeatedly "loading" this view: are you reusing the same view controller instance, or creating a new one each time?
benzado
A: 

no alloc is required when you create the array

NSArray *myArray = [[NSArray alloc] initWithObjects: @"Add", @"Edit", nil];

use :

  • (id)arrayWithObjects:(id)firstObj, ...

    try this way, this also do not need release

Robin
I had that originally, changed it in an attempt to narrow the problem by avoiding autoreleased objects.
Alex Gosselin
.... so what the variant scope of the 'segmentControl' ? try add [segmentControl release];
Robin
sorry , I have add you code block in a clean basic app, and use Instruments to trace the Leak issue , but no memory leak was occupy ... maybe my trace way is not correct ? I guess that seem other code cause the problem ....
Robin
A: 

Is segmentControl a property? Do you nil it in viewDidUnload?

David Dunham
In dealloc i have segmentControl released, what is the effect of setting it to nil in viewDidUnload?
Alex Gosselin
You didn't answer my question: is it a property? If so, and it's defined with "retain" then setting it does a retain, and your release only gets rid of the alloc.
David Dunham