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" <gpar...@apple.com> wrote:
>On Apr 22, 2014, at 6:49 PM, Jens Alfke <j...@mooseyard.com> wrote:
>> On Apr 22, 2014, at 6:38 PM, Varun Chandramohan
>><varun.chandramo...@wontok.com> 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 gpar...@apple.com Runtime Wrangler
>
>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
