Re: String memory leak
Re: String memory leak
- Subject: Re: String memory leak
- From: Bruce Truax <email@hidden>
- Date: Sat, 01 Apr 2006 08:24:58 -0500
- Thread-topic: String memory leak
On 4/1/06 8:01 AM, "Chris Lewis" <email@hidden> wrote:
> Hey Bruce,
> It's not clear what you intend to do with the string: how long it
> lives and when it's released.
>
> What you currently get with stringWithFormat is an autoreleased
> string. I don't know whether surface is a class you have written. If
> it is, you should make the setGlass method in the surface class retain
> that string it recieves, or it'll get deallocated at the end of the
> event loop. If it's an API class, you can assume that the surface
> object handles stuff for you.
>
> By calling initWithFormat, you allocate a new string that you own
> (this is like getting the autoreleased string and retaining it). You
> must release it yourself, or it'll never be deallocated. You don't
> want to do this here. This method doesn't care about the string, only
> the surface object does. Use the code you already have.
>
> Either way: those strings are going to leak if you don't clean up when
> you're doing with the surface object.
I do clean up.
>
> Look through your code.
> 1. Do you ever deallocate the surfaces at all? A gotcha I read about
> is that if you release the NSArray, all you do is release the NSArray,
> and not the objects inside it. You need to release those first. If
> they don't get released, you'll leak the strings as well.
At the time when I check for the leak ACSurface is still in the array.
> 2. If surface is a class you have defined: Do you have a
> -(void)dealloc method defined, where you release your instance
> variables? Like
>
> - (void)dealloc
> {
> [glass release];
> [surfaceNumber release]; // Assuming surface number is an NSNumber
> [super release];
> }
Yup. I do have a dealloc method and it does just what you state.
>
> It sounds like you haven't read too much about Cocoa memory management
> (the difference between an autoreleased object and and allocated
> object is very important!). I have found it quite tough to get my head
> around, and even now I do seem to grasp the concepts well enough, I
> still have frustrating evenings trying to find objects that aren't
> getting deallocated.
>
> http://www.macdevcenter.com/pub/a/mac/2001/07/27/cocoa.html
>
> Might help you get started.
Actually I have read this and I was going through my code cleaning up leaks
when I found this one and I cannot see to discern its cause.
>
> The ObjectAlloc app (with your Developer Tools) is also very useful,
> run it and see what else is being allocated without deallocation. I
> would expect to see a lot of surface objects that you don't use any
> more.
>
I will give that a try.
Thanks.
Bruce
> HTH
> Chris
>
> On 4/1/06, Bruce Truax <email@hidden> wrote:
>> The command line tool "leaks" is telling me that I have an 80 byte leak of
>> type NSCFString everytime I execute the following method:
>>
>> - (void)GLASS:(NSString *)parameterString
>> {
>> [aSurface setGlass:[NSString stringWithFormat:
>> @"GLASS %@", parameterString]];
>> [aSurface setSurfaceNumber:surfaceNumber];
>> surfaceNumber++;
>> [surfaceArray addObject:aSurface];
>> aSurface = [[ACSurface alloc]init];
>>
>> }
>>
>> Here is the Leaks report:
>> Leak: 0x060d9410 size=80 instance of 'NSCFString'
>> 0xa073a674 0x0001078c 0x45474c41 0x5353204d .s.t....EGLASS M
>> 0x4f44454c 0x20312e36 0x39313030 0x3230202d ODEL 1.6910020 -
>> 0x312e3030 0x30303030 0x3030452d 0x30332020 1.00000000E-03
>> 0x302e3030 0x30303030 0x3030452b 0x30302020 0.00000000E+00
>> 0x302e3030 0x30303030 0x3030452b 0x30300054 0.00000000E+00.T
>>
>> I assume that I am doing something wrong with memory management in the line:
>>
>> [aSurface setGlass:[NSString stringWithFormat:
>> @"GLASS %@", parameterString]];
>>
>> Should I be using the following instead?
>>
>> [aSurface setGlass:[[NSString alloc] initWithFormat:
>> @"GLASS %@", parameterString]];
>>
>> This really has me puzzled.
>>
>> Thanks.
>>
>> Bruce
>>
>>
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Cocoa-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
--
____________________________________________________________
Bruce E. Truax email: email@hidden
Optical Engineering Consultant
Diffraction Limited Design LLC
388 Wedgewood Road voice: 860-276-0450
Southington, CT 06489 fax: 860-620-9026
http://www.dld-llc.com
_____________________________________________________________
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden