• 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: Memory Leaks and ARC
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory Leaks and ARC


  • Subject: Re: Memory Leaks and ARC
  • From: Varun Chandramohan <email@hidden>
  • Date: Wed, 23 Apr 2014 04:27:06 +0000
  • Thread-topic: Memory Leaks and ARC

That makes sense. I am now able to see the issue after setting
OBJC_DEBUG_MISSING_POOLS=YES. My original code was using CoreFoundation
extensively and I introduced Foundation APIs recently. I think this issue
got introduced after that.
Since this is non-cocoa application (daemon), what I have is basically,

Main(){

Init code

InstallRunLoopSources();
// Go go gadget server!

    if (err == 0) {
        asl_log(gAslClient, NULL, ASL_LEVEL_NOTICE,  "Initialisation
successful. Entering run loop.\n");

        CFRunLoopRun();



}

This is just a brief overview, so my guess is that I need to put create
auto release pool here for NS objects that are used. Is it a good idea to
put in pools for each runloop callbacks? I already have pool in place for
all threads I created using pthread_create. The only place is missing is
the main thread as show above.

Regards,
Varun

On 23/04/2014 2:05 pm, "Greg Parker" <email@hidden> wrote:

>On Apr 22, 2014, at 6:49 PM, Jens Alfke <email@hidden> wrote:
>> On Apr 22, 2014, at 6:38 PM, Varun Chandramohan
>><email@hidden> wrote:
>>> However when I
>>> run the same code in older OS 10.7.x and run leaks there I noticed big
>>> dump of leaks and my daemon (runs without a UI) has numerous
>>>_NSCFString
>>> autoreleased with no pool in place - just leaking -
>>
>> If you¹re creating NSThreads, make sure the main/top-level method of
>>each thread has an autorelease pool. I seem to recall some change in
>>functionality there in recent OS versions.
>>
>>> break on objc_autotreleaseNoPool() to debug
>>
>> Šbut instead of listening to me speculate, you could set a breakpoint
>>on that function and find out exactly where the leak is happening.
>
>In recent OS versions, calls to +load methods are automatically wrapped
>in autorelease pools. Older OS versions did not do this. This is one
>possible cause of "autoreleased with no pool in place" on older OS
>versions. In this case there is no leaked or abandoned memory on recent
>OS versions, but there will be leaks on older OS versions.
>
>In recent OS versions, the runtime automatically creates an autorelease
>pool on a thread if you call -autorelease without one in place. This pool
>will live as long as the thread does. This is another possible cause of
>"autoreleased with no pool in place" on older OS versions. In this case
>there may be abandoned memory on recent OS versions, if your thread is
>long-lived and lots of objects fall into this pool. You can run with
>OBJC_DEBUG_MISSING_POOLS=YES to get "autorelease with no pool in place"
>messages here that are similar to the ones you get on older OS versions.
>
>(History: some OS version accidentally introduced the
>create-new-pool-automatically behavior in some cases. We couldn't undo
>that without breaking some apps that shipped in the meantime, so instead
>we formalized it and added the OBJC_DEBUG_MISSING_POOLS=YES log.
>Somewhere around here I have a feature request for Instruments detection
>of "old" autorelease pools that are hanging on to objects that should be
>dead.)
>
>
>--
>Greg Parker     email@hidden     Runtime Wrangler
>
>


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please 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


References: 
 >Memory Leaks and ARC (From: Dave <email@hidden>)
 >Re: Memory Leaks and ARC (From: Quincey Morris <email@hidden>)
 >Re: Memory Leaks and ARC (From: Varun Chandramohan <email@hidden>)
 >Re: Memory Leaks and ARC (From: Jens Alfke <email@hidden>)
 >Re: Memory Leaks and ARC (From: Greg Parker <email@hidden>)

  • Prev by Date: Re: Memory Leaks and ARC
  • Next by Date: Re: Layout-triggered animation
  • Previous by thread: Re: Memory Leaks and ARC
  • Next by thread: Re: Memory Leaks and ARC
  • Index(es):
    • Date
    • Thread