Re: [newbie] NSString code so it won't leak
Re: [newbie] NSString code so it won't leak
- Subject: Re: [newbie] NSString code so it won't leak
- From: James DiPalma <email@hidden>
- Date: Wed, 11 Sep 2002 17:19:28 -0400
Anyhow, when I run the program under ObjectAlloc what
I saw was that everytime NSTimer would fire objects of
type NSString (or CFString, I forget) would just stack
up.
I did this exact same thing and also saw CFStrings stack up. I printed
these CFSTrings out for you and they where all allocated from within a
call to NSLog. Maybe you should try using printf() in your code and see
what happens?
If you "Pause" ObjectAlloc while a timer is running in
the program being tested the whole things crashes when
the timer fires. (at least this is what I found in
this example).
And you don't think your app crashes because you released sender and
filedata? On my machine without ObjectAlloc involved at all and without
pausing, your app crashed after printing "URLHRDFL":
#1 0x708af9d8 in -[NSURLHandle flushCachedData] ()
When I remove [filedata release] and [sender release] it worked fine.
Also, if I don't free "sender" in
URLHandleResourceDidFinishLoading objects of type
CFHTPPURLHandle (or something like that) and a bunch
of what looked to be NSURL releated objects would
start to stack up (one object for each time the timer
would fire).
Is this a justification for releasing sender? You don't retain sender,
nor do you alloc sender, nor do you copy sender. A few residual objects
might be a leak or might be sitting around for some valid reason. Do you
know why? if not, don't go releasing things willy nilly.
Also, if I don't free "sender" in
or "If you don't release sender"; I don't want to appear mean, but
please be careful with your statements.
You have received a dozen responses saying, "buddy, your string code
does not leak." and chosen to disregard them. I have looked at your
code, compiled it, ran it, and made suggestions and you chose to
disregard my comments. You have clearly read and understood Apple's
documentation on object ownership and chosen to write code that does not
follow Apple's guidelines.
So, you have no actual evidence that your strings are actually leaking
and you persist in rejecting Apple's guidelines for memory management,
but you persist in thinking an NSString leak is causing your residual
strings. Until you have a good idea what those residual strings are,
I'll put my money on something besides NSString's methods for
substringToIndex and substringFromIndex.
-jim
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.