Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface
Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface
- Subject: Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface
- From: Sandy McGuffog <email@hidden>
- Date: Thu, 17 Sep 2015 14:15:20 +0200
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 <email@hidden> wrote:
>
>
>> On 16 sept. 2015, at 18:58, Quincey Morris <email@hidden> wrote:
>>
>> On Sep 16, 2015, at 04:00 , Jean Suisse <email@hidden> 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 (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
_______________________________________________
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