• 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: Re: NSTask memory leak
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: NSTask memory leak


  • Subject: Re: Re: NSTask memory leak
  • From: "Shawn Erickson" <email@hidden>
  • Date: Wed, 29 Nov 2006 11:25:26 -0800

On 11/29/06, Stefan Werner <email@hidden> wrote:

On Nov 29, 2006, at 7:34 PM, Shawn Erickson wrote: > It doesn't even work as long as their is a single instance since > autorelease pools are per thread (uses thread local storage).

So I tried that that too, no dice.
I created one NSAutorelasePool per thread, released it when the
thread quit - still leaking.

How long do these threads exists? How many objects get created while the thread exits?

Review...
<http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/AutoreleasePools.html#//apple_ref/doc/uid/20000047-1041876-CJBFEIEG>

> Your management of the NSTask instance looks correct but I cannot
> comment on the other Cocoa objects created directly or indirectly by
> your C++ class since we don't know  if an autorelease pools exists at
> the time the C++ method is called or how such an autorelease pool is
> being managed.

ObjectAlloc shows me that the NSTask instance is the leak, so the
other stuff appears to be behaving correctly.

Is your C++ destructor getting called?

> Ideally each of your C++ methods (not just the constructor) should
> create an autorelease pool before sending any messages and release
> that pool before returning from the C++ method

That was actually my initial approach, I created an autorelease pool
in the first line of every C++ method and releasing in right before
it returns. Was leaking just the same.

Then likely autoreleased items aren't your issue but you should still be doing this.

> unless you know that
> 100% of the time the thread calling the C++ method will have a
> autorelease pool in place (that gets drained in a sensible fashion
> while the application is executing).

Which actually is. The first thing that my C++ class creates is an
AutoreleasePool, very last thing it does is releasing that pool,
which pretty much assures that during the lifetime of that object, a
pool is in place as long as all the function calls to that object
come from the same thread (which they do).

Again autorelease pools are per thread and maintained in a stack, they shouldn't be associated with an instance of an object. If other code called by that thread allocates or releases autoreleeas pools the stack of pools could easily break the assumption you outlined above.... invalidating the autorelease pool you associated with the object.

If, at any point, there would not be an AutoreleasePool where one is
required, I should see a message about this in the console, right?

Correct. Of course just because you have an autorelease pool in place doesn't mean that that autorelease pool is getting drained in a sensible fashion.

-Shawn
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: NSTask memory leak
      • From: Stefan Werner <email@hidden>
References: 
 >NSTask memory leak (From: Stefan Werner <email@hidden>)
 >Re: NSTask memory leak (From: "Shawn Erickson" <email@hidden>)
 >Re: NSTask memory leak (From: Stefan Werner <email@hidden>)
 >Re: Re: NSTask memory leak (From: "Shawn Erickson" <email@hidden>)
 >Re: NSTask memory leak (From: Stefan Werner <email@hidden>)

  • Prev by Date: Re: Slightly OT: SIGKILL (force quit) and child process termination
  • Next by Date: Re: NSTask memory leak
  • Previous by thread: Re: NSTask memory leak
  • Next by thread: Re: NSTask memory leak
  • Index(es):
    • Date
    • Thread