> On Sep 16, 2015, at 11:58 AM, Quincey Morris
> <quinceymor...@rivergatesoftware.com> wrote:
>
> On Sep 16, 2015, at 04:00 , Jean Suisse <jean.li...@gmail.com
> <mailto:jean.li...@gmail.com>> wrote:
>>
>> Does anyone know what to try / measure / observe to get more clues?
>
> It seems you’re “losing” free memory fast enough for this to be visible using
> heap generations in Instruments’ Allocations.
If the memory’s actually being leaked, the “leaks” too might help too. Here’s
how I look for something using Allocations, though:
1. Make sure the instrument is set up to record refcounts before you start (the
Leaks instrument automatically sets up an Allocations instrument this way, but
the Allocations instrument doesn’t by default. There’s a check box in the
right-hand pane).
2. Start recording, and sort the list of objects by the “Category” field.
3. After it’s collected enough data, find the class of object that you're
storing in the property that might be leaking in the list. Click the little
arrow thing that appears next to it when you hover over it.
4. You’ll see a list of instances of your class. You can click the little gear
icon in the right-hand pane and choose whether to show all objects, live and
dead, or only live ones. Showing all objects can show you whether any of these
objects have been deallocated at all; if none have, there’s your problem.
5. If you can find an instance of your class in the list that really *should*
have been deallocated, but hasn’t, you can click on its little arrow thing, and
get its history. You can now see all the places where it’s been alloc,
retained, released, autoreleased, etc. If you click the little icon that looks
like Ⓔ in the sidebar, you can see a full stack trace of the line that caused
the action you’ve got selected.
You know, though, if all you’re trying to do is avoid KVO notifications getting
fired on threads other than the main thread, you could just turn off automatic
KVO notifications for those properties and fire them yourself on the main
thread. If you just implement the (really baroquely named)
+automaticallyNotifiesObserversOf<Key> to return NO, and then have your setter
manually call -willChangeValueForKey: and -didChangeValueForKey: on the main
dispatch queue, with a lock or sync queue to make the variable atomic (or just
back it by a private atomic property), you can avoid the need for your UI
update polling altogether. If your property name is “foo”, something like this
(warning: written in Mail):
@interface MyClass ()
@property (atomic) MyObject *privateFoo;
@end
@implementation MyClass
+ (BOOL)automaticallyNotifiesObserversOfFoo {
return NO;
}
- (MyObject *)foo {
return self.privateFoo;
}
- (void)setFoo:(MyObject *)foo {
dispatch_async(dispatch_get_main_queue(), ^{
[self willChangeValueForKey:@“foo”];
});
self.privateFoo = foo;
dispatch_async(dispatch_get_main_queue(), ^{
[self didChangeValueForKey:@“foo”];
});
}
@end
Voilà; you can now just call the setter directly from your worker queues
without any special shenanigans, and all KVO notifications for foo are now sent
on the main thread; no uncommitted CATransactions or other weirdness caused by
UI threads getting updated on the wrong thread.
Charles
_______________________________________________
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
