Thanks for your insight Dave,
In my current implementation I do have an autorelease pool being created and
released at the end of main, as well as inside each posted notification that
NSFileHandle posts on each background thread. Upon further inspection the
largest culprits are not CFConstantStringRefs but instead non-object
allocations inside libsqlite3.dylib being called by sqlite3MemMalloc. The
constant strings are indeed building but are not the largest allocations.
With one save of the managedObjectContext libsqlite3.dylib mallocs 35 objects
that are still considered "live" even after the NSOperation that is the root of
the call stack has since been freed.
Here is the call-stack for one of the allocations since they all seem to follow
the same call stack:
0 libsqlite3.dylib sqlite3MemMalloc
1 libsqlite3.dylib mallocWithAlarm
2 libsqlite3.dylib pcache1Fetch
3 libsqlite3.dylib sqlite3PcacheFetch
4 libsqlite3.dylib sqlite3PagerAcquire
5 libsqlite3.dylib sqlite3BtreeBeginTrans
6 libsqlite3.dylib btreeCursor
7 libsqlite3.dylib sqlite3InitOne
8 libsqlite3.dylib sqlite3Init
9 libsqlite3.dylib sqlite3Pragma
10 libsqlite3.dylib yy_reduce
11 libsqlite3.dylib sqlite3Parser
12 libsqlite3.dylib sqlite3RunParser
13 libsqlite3.dylib sqlite3LockAndPrepare
14 CoreData -[NSSQLiteConnection _executeSQLString:]
15 CoreData -[NSSQLiteConnection _configurePragmaOptions]
16 CoreData -[NSSQLiteConnection connect]
17 CoreData -[NSSQLCore _loadOrSetMetadata]
18 CoreData -[NSSQLCore _ensureMetadataLoaded]
19 CoreData -[NSSQLCore
initWithPersistentStoreCoordinator:configurationName:URL:options:]
20 CoreData -[NSPersistentStoreCoordinator
addPersistentStoreWithType:configuration:URL:options:error:]
21 MAID -[MIMaidServer persistentStoreCoordinator]
/Users/kevin/Desktop/MAID_Workspace/MAID/MAID/Source/MIMaidServer.m:466
22 MAID -[MIMaidServer managedObjectContext]
/Users/kevin/Desktop/MAID_Workspace/MAID/MAID/Source/MIMaidServer.m:492
23 MAID -[MIMaidOperation managedObjectContext]
/Users/kevin/Desktop/MAID_Workspace/MAID/MAID/Source/MIMaidOperation.m:432
24 MAID -[MIMaidOperation logClientData:]
/Users/kevin/Desktop/MAID_Workspace/MAID/MAID/Source/MIMaidOperation.m:242
25 MAID -[MIMaidOperation handleIncommingData:]
/Users/kevin/Desktop/MAID_Workspace/MAID/MAID/Source/MIMaidOperation.m:230
26 MAID -[MIMaidOperation dataReadFromClient:]
/Users/kevin/Desktop/MAID_Workspace/MAID/MAID/Source/MIMaidOperation.m:210
27 Foundation _nsnote_callback
28 CoreFoundation __CFXNotificationPost
29 CoreFoundation _CFXNotificationPostNotification
30 Foundation -[NSNotificationCenter postNotificationName:object:userInfo:]
31 Foundation _performFileHandleSource
32 CoreFoundation __CFRunLoopDoSources0
33 CoreFoundation __CFRunLoopRun
34 CoreFoundation CFRunLoopRunSpecific
35 Foundation -[NSRunLoop(NSRunLoop) runMode:beforeDate:]
36 Foundation -[NSRunLoop(NSRunLoop) run]
37 MAID -[MIMaidOperation main]
/Users/kevin/Desktop/MAID_Workspace/MAID/MAID/Source/MIMaidOperation.m:165
38 Foundation __NSThread__main__
39 libSystem.B.dylib _pthread_start
40 libSystem.B.dylib thread_start
With regard to the CFSTR being static within the executable
CFStringRef MICreateVersionStringFromVersionValue( UInt32 versionValue )
{
UniChar upperBase = 0;
UniChar lowerBase = 0;
UniChar major = 0;
UniChar minor = 0;
CFStringRef hexStringRef = CFStringCreateWithFormat( NULL, NULL,
CFSTR("%x"), versionValue ); <----- Instruments is hi-lighting this line as
an allocation.
CFIndex sizeMatters = CFStringGetLength( hexStringRef );
//CFIndex charactersReturned = 0;
if ( sizeMatters > 3 )
{
CFStringGetCharacters( hexStringRef, CFRangeMake( sizeMatters -
4, 1 ), &upperBase );
}
CFStringGetCharacters( hexStringRef, CFRangeMake( sizeMatters - 3, 1 ),
&lowerBase );
CFStringGetCharacters( hexStringRef, CFRangeMake( sizeMatters - 2, 1 ),
&major );
CFStringGetCharacters( hexStringRef, CFRangeMake( sizeMatters - 1, 1 ),
&minor );
CFStringRef versionStringRef = CFStringCreateWithFormat( NULL, NULL,
CFSTR("%c%c.%c.%c"), upperBase, lowerBase, major, minor ); <----- Instruments
is hi-lighting this line as an allocation even though it is being released by
the caller of the function.
CFRelease( hexStringRef );
return versionStringRef;
}
The returned versionStringRef is being released from the caller of the function
and none of the other tools are reporting this as a leak so I'm not sure why
the system is still considers any of the memory "live".
Thanks for your help in this matter, it's been driving me crazy for a few days.
Sincerely,
Kevin Ross
On Oct 1, 2010, at 1:00 AM, Dave Keck wrote:
> Since you're writing a daemon, you'll need to handle autorelease-pool
> creation and draining manually (something that's normally handled by
> NSApplication in standard AppKit apps.) Perhaps objects are
> autoreleased and placed in the root autorelease pool (that you might
> be creating in main() or the like) which is never drained?
>
> Also, how many strings are leaking? I know the frameworks cache
> NSNumber instances; I'm not sure about immutable strings.
>
>> I have run the daemon through the clang static analyzer and the Instruments
>> leaks tool but none are reporting any leaks. I have even downloaded a fresh
>> copy of valgrind from svn and it too is not finding anything. The
>> instruments allocation monitor is reporting that there are
>> CFConstantStringRefs that Foundation is allocating from internal methods and
>> CFSTR macros that I am using in some functions. I'm happy to provide more
>> details of the actual call-stacks and code if necessary.
>
> A pedantic detail: note that strings created with CFSTR exist
> statically within your executable (they aren't dynamically allocated)
> and therefore aren't leaks.
>
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
