• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [newbie] NSString code so it won't leak
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [newbie] NSString code so it won't leak


  • Subject: Re: [newbie] NSString code so it won't leak
  • From: Shawn Erickson <email@hidden>
  • Date: Wed, 11 Sep 2002 22:21:46 -0700

After a little more digging it looks like the autorelease pool is only getting cleaned (using the "private" method _NSPopAutoreleasePool) from inside of NSApplication's run method when the application gets another event (causes the event loop to go around again).

This seems strange to me... I thought that NSTimers would tickle the event loop such that the current autorelease pool would be clean/dealloced after the firing on the timer.


-Shawn

On Wednesday, September 11, 2002, at 08:59 PM, Shawn Erickson wrote:


On Wednesday, September 11, 2002, at 02:19 PM, James DiPalma wrote:

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.

Well his strings are leaking but not for the reason Dean believes. I have verified, using OmniObjectMeter, that both substringToIndex and substringFromIndex do return autorelease objects as expected. The issue appears to be that the autorelease pool that they are being put into is _not_ being released.

I am still trying to figure out why... something in URL code base appears to be doing something incorrectly (his method is called by the URL code base in Foundation). I did wrap the call to [self extractWithData:[sender resourceData]]; with an autorelease pool an the leaks went away (wrapping the timer call back didn't work). So it is something mucked up in NSURL/NSURLHandle or a side effect of doing something wrong with the URL classes.

So Dean you are right and wrong. :-)

I would back up James on some of his notes about you releasing things when you should not be doing so and that release != dealloc ("free"). I have a fixed up version of your test app if you want it. The unneeded releases are causing your "app" to crash.

-Shawn
_______________________________________________
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.

References: 
 >Re: [newbie] NSString code so it won't leak (From: Shawn Erickson <email@hidden>)

  • Prev by Date: Re: Final round with NSTIFFCompressionCCITTFAX3
  • Next by Date: Re: [newbie] NSString code so it won't leak
  • Previous by thread: Re: [newbie] NSString code so it won't leak
  • Next by thread: Re: [newbie] NSString code so it won't leak
  • Index(es):
    • Date
    • Thread