Based on that, where you’re losing memory is to bitmapped backed CALayers that aren’t being released. Depending on the size of the bitmap, they can be big - MBs each. They are being allocated in the Kernel, so aren’t showing in instruments. Why they aren’t being released, I couldn’t say. Maybe a retain loop, maybe an animation that never finishes, etc, etc. But I’d starting looking (a) by removing any Core animation you can, and (b) I’d look at any NSWindows/NSViews/NSControllers that aren’t being released when you close all visible windows.
Sandy > On Sep 17, 2015, at 1:13 PM, Jean Suisse <jean.li...@gmail.com> wrote: > > >> On 16 sept. 2015, at 18:58, Quincey Morris >> <quinceymor...@rivergatesoftware.com> wrote: >> >> On Sep 16, 2015, at 04:00 , Jean Suisse <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. The difficulty with >> marking generations is that you’d really like the app (at least its >> memory-wasting activities) to go quiescent long enough and often enough to >> let you set marks when it’s not doing anything. >> >> You could do this by changing your timer to fire (say) every minute instead >> of every second. In Instruments, wait until you see a UI update, then wait >> about 30 more seconds, then mark the generation. Do this several times, and >> you should be able find out exactly what’s being leaked. (“Why” might be >> harder.) > > > I did that. All I see is that the memory is taken (not leaked) after > __CFRunLoopDoObservers and CA::Transaction::commit(). > > Bytes Used Count Symbol Name > 30.61 MB 97.0% 11645 start > 30.61 MB 97.0% 11645 main > 30.61 MB 97.0% 11645 NSApplicationMain > 30.61 MB 97.0% 11645 -[NSApplication run] > 30.59 MB 96.9% 11644 -[NSApplication > nextEventMatchingMask:untilDate:inMode:dequeue:] > 30.59 MB 96.9% 11643 _DPSNextEvent > 30.59 MB 96.9% 11643 > _BlockUntilNextEventMatchingListInModeWithFilter > 30.59 MB 96.9% 11643 ReceiveNextEventCommon > 30.59 MB 96.9% 11643 RunCurrentEventLoopInMode > 30.59 MB 96.9% 11643 CFRunLoopRunSpecific > 29.27 MB 92.7% 161 __CFRunLoopDoObservers > 29.27 MB 92.7% 161 > __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ > 29.27 MB 92.7% 161 > CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) > 28.93 MB 91.6% 139 CA::Transaction::commit() > 28.93 MB 91.6% 139 > CA::Context::commit_transaction(CA::Transaction*) > 28.92 MB 91.6% 22 > CA::Layer::layout_and_display_if_needed(CA::Transaction*) > 28.92 MB 91.6% 22 > CA::Layer::display_if_needed(CA::Transaction*) > 28.92 MB 91.6% 22 -[_NSViewBackingLayer display] > 28.92 MB 91.6% 22 _NSBackingLayerDisplay > 28.92 MB 91.6% 22 CA::Layer::display_() > 28.92 MB 91.6% 22 x_blame_allocations > 28.92 MB 91.6% 22 > ___ZN2CA5Layer8display_Ev_block_invoke > 28.92 MB 91.6% 22 CABackingStoreUpdate_ > 28.76 MB 91.1% 2 > CA::Render::Shmem::new_bitmap(unsigned int, unsigned int, unsigned int, > unsigned int) > 28.76 MB 91.1% 2 > CA::Render::Shmem::new_shmem(unsigned long) > 28.76 MB 91.1% 2 vm_allocate > 28.76 MB 91.1% 2 mach_vm_allocate > > _______________________________________________ > > 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/mcguffogl%40gmail.com > > This email sent to mcguff...@gmail.com _______________________________________________ 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
