• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Finding memory leaks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Finding memory leaks


  • Subject: Re: Finding memory leaks
  • From: Rob Petrovec via Cocoa-dev <email@hidden>
  • Date: Wed, 20 May 2020 14:46:51 -0600

Yes, there is more than one way to skin a cat.  Use whatever methods work for
you.  But keep in mind that your experiences may not be the same as others
because your code base is obviously going to be different.  So I would not
recommend avoiding one tool over another just because it didn’t work for you.
It just might work for someone else.

—Rob


> On May 20, 2020, at 2:44 PM, Alex Zavatone <email@hidden> wrote:
>
> For iOS, I’ve found that setting up a test to replicate the memory leak, or
> simply running tests is a great idea.  Here’s where Instruments sucks.
> Running on the Simulator, Instruments often drops the connection to the
> target.  Also, I’ve gotten Instruments files that are 30 GB, while just
> setting a breakpoint in a test and invoking the memory graph debugger lets
> you see the relationship between objects and save a .memgraph document so
> that you can open it again.
>
> Here are some of the horror stories caused by my former team.
>
> We had 1400 of them.
>
> https://imgur.com/Pq0eEkf <https://imgur.com/Pq0eEkf>
> https://imgur.com/mavOyOT <https://imgur.com/mavOyOT>
> https://imgur.com/3mnRUa1 <https://imgur.com/3mnRUa1>
> https://imgur.com/4nksFco <https://imgur.com/4nksFco>
>
> So much easier than walking the stack backtrace, but when you enable logging
> in the scheme Diagnostics, you also have your stack backtrace, so you can see
> where objects have multiple references causing the retain cycles and examine
> the backtrace if you want to.
>
> Simply select the object and the backtrace is in the right Inspector pane.
>
> - Alex Zavatone
>
>> On May 20, 2020, at 2:58 PM, Rob Petrovec <email@hidden
>> <mailto:email@hidden>> wrote:
>>
>> I’ve had a lot of success with Instruments leaks traces.  In the
>> retain/release world we live in, knowing the backtrace to where the object
>> was created isn’t enough.  Instruments gives a nice UI to walk the
>> retain/release history of an object, and the backtrace of each
>> retain/autorelease/release.  Using a memgraph as Alex suggested is also
>> good, but can sometimes be hard to parse when the map is HUGE!  Either way,
>> both Instruments and memgraphs are tools you should definitely learn & use.
>>
>> My only real gripe is that both Instruments & memgraphs don’t handle C++
>> objects very well.  It would be nice if they understood shared_ptr &
>> unique_ptr.
>>
>> —Rob
>>
>>
>>> On May 20, 2020, at 9:16 AM, Alex Zavatone via Cocoa-dev
>>> <email@hidden <mailto:email@hidden>> wrote:
>>>
>>> Also, in your run scheme, enable the Diagnostics for Logging > Malloc Stack
>>> > Live Allocations Only.
>>>
>>>> On May 20, 2020, at 10:08 AM, Georg Seifert via Cocoa-dev
>>>> <email@hidden <mailto:email@hidden>> wrote:
>>>>
>>>> You need to check the backtrace where the leaking object was created.
>>>> Sometimes it points to a line that has nothing to do with the leak, it is
>>>> just triggering it.
>>>>
>>>> g
>>>>
>>>>> On 20.05.2020, at 16:03, Gabriel Zachmann via Cocoa-dev
>>>>> <email@hidden <mailto:email@hidden>
>>>>> <mailto:email@hidden <mailto:email@hidden>>>
>>>>> wrote:
>>>>>
>>>>> I have a few stupid questions regarding (potential) memory leaks,
>>>>> so please bear with me.
>>>>> First of all, my code is ARC managed.
>>>>>
>>>>> I tried the Leaks tool of Instruments.
>>>>>
>>>>> It tells me, if i understand correctly, that I have a leak at this line
>>>>> of my code:
>>>>>
>>>>> CFDictionaryRef fileProps = CGImageSourceCopyPropertiesAtIndex(
>>>>> new_image, 0, NULL );
>>>>>
>>>>> This line is in a method I declared like that:
>>>>>
>>>>> - (void) loadNextImageWithIndex: (unsigned long) next_index image:
>>>>> (CGImageRef *) next_image
>>>>>                   withProps: (CFDictionaryRef *) next_props
>>>>>
>>>>> and at the end of the function, I pass fileProps back like so
>>>>>
>>>>> *next_props = fileProps;
>>>>>
>>>>> The caller then makes a copy of next_props for later use, and CFRelease's
>>>>> next_props.
>>>>> (That copy is also released later.)
>>>>>
>>>>> So it is unclear to me why the Leaks tool thinks that the above line
>>>>> leaks memory.
>>>>>
>>>>>
>>>>>
>>>>> Another area of questions is around CALayer's and images.
>>>>> I create images like so:
>>>>>
>>>>> CGImageRef newImageRef = CGImageSourceCreateThumbnailAtIndex( new_image,
>>>>> 0,
>>>>>                                                            (__bridge
>>>>> CFDictionaryRef) imageOpts );
>>>>> I store newImageRef in an array (history_of_images).
>>>>> Then, I assign newImageRef to a CALayer like this:
>>>>>
>>>>> imgLayer.contents = (__bridge id)(newImageRef);
>>>>>
>>>>> At some point later, when the layer is no longer part of the layer
>>>>> hierarchy, I release it like this:
>>>>>
>>>>> CGImageRelease( history_of_images[k].img );
>>>>>
>>>>> Can you spot any point in this sequence where there could be a memory
>>>>> leak?
>>>>> Does any of the assignments I described create a copy?
>>>>> Should I release CALayer's myself after I have removed it from its super
>>>>> layer?
>>>>> By the growth of the memory usage of my app I suspect that the images
>>>>> I've been loading keep lingering on somewhere in memory.
>>>>>
>>>>>
>>>>> Another area of questions centers around dispatch queues.
>>>>> The above stuff (loading, thumbnail creation) is, mostly, done in a
>>>>> background thread via dispatch_async.
>>>>> I have tried to put an @autoreleasepool around the code that runs in the
>>>>> background thread, to no avail.
>>>>> (My code is under ARC.)
>>>>>
>>>>> But in Instruments, all indications (e.g., Heaviest stack trace) point to
>>>>> CGImageSourceCreateThumbnailAtIndex, that shows a stack trace like that:
>>>>>
>>>>> 13 libdispatch.dylib  269.42 KB     _dispatch_client_callout
>>>>> 12 ArtSaverApp  269.42 KB     -[ArtSaverView loadNextImage]
>>>>> /Users/zach/Code/ArtSaver/ArtSaverView.m:2045
>>>>> 11 ArtSaverApp  269.42 KB     -[ArtSaverView
>>>>> loadNextImageWithIndex:image:withProps:]
>>>>> /Users/zach/Code/ArtSaver/ArtSaverView.m:2083
>>>>> 10 ImageIO  248.44 KB     CGImageSourceCopyPropertiesAtIndex
>>>>> 9 ImageIO  248.44 KB     IIOImageSource::copyPropertiesAtIndex(unsigned
>>>>> long, IIODictionary*)
>>>>> 8 ImageIO  248.30 KB
>>>>> IIOImageSource::getPropertiesAtIndexInternal(unsigned long,
>>>>> IIODictionary*)
>>>>> 7 ImageIO  244.78 KB     IIOImageSource::makeImagePlus(unsigned long,
>>>>> IIODictionary*)
>>>>> 6 ImageIO  100.08 KB
>>>>> IIO_Reader_AppleJPEG::initImageAtOffset(CGImagePlugin*, unsigned long,
>>>>> unsigned long, unsigned long)
>>>>> 5 ImageIO   97.58 KB     IIOReadPlugin::callInitialize()
>>>>> 4 ImageIO   93.64 KB     AppleJPEGReadPlugin::initialize(IIODictionary*)
>>>>> 3 ImageIO   52.00 KB     AppleJPEGReadPlugin::appleJPEGDecodeSetup()
>>>>> 2 AppleJPEG   52.00 KB     applejpeg_decode_create
>>>>> 1 libsystem_malloc.dylib   52.00 KB     malloc
>>>>> 0 libsystem_malloc.dylib   52.00 KB     malloc_zone_malloc
>>>>>
>>>>> (ArtSaverApp is, of course, my code.)
>>>>> Similar backtraces show up when I click on the various Malloc leaks in
>>>>> the Leaks by Backtrace view.
>>>>> Almost all of them go through CGImageSourceCopyPropertiesAtIndex(), and
>>>>> the responsible library is
>>>>> ImageIO.
>>>>>
>>>>>
>>>>> Thanks a lot in advance for all kinds of insights and hints.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Cocoa-dev mailing list (email@hidden
>>>>> <mailto: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
>>>>> <http://lists.apple.com/>
>>>>>
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>>
>>>>> This email sent to email@hidden <mailto:email@hidden>
>>>>> <mailto:email@hidden <mailto:email@hidden>>
>>>>
>>>> _______________________________________________
>>>>
>>>> Cocoa-dev mailing list (email@hidden
>>>> <mailto:email@hidden> <mailto:email@hidden
>>>> <mailto: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
>>>> <http://lists.apple.com/> <http://lists.apple.com/
>>>> <http://lists.apple.com/>>
>>>>
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden <mailto:email@hidden> <mailto:email@hidden
>>>> <mailto:email@hidden>>
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden
>>> <mailto: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
>>> <http://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

References: 
 >Finding memory leaks (From: Gabriel Zachmann via Cocoa-dev <email@hidden>)
 >Re: Finding memory leaks (From: Georg Seifert via Cocoa-dev <email@hidden>)
 >Re: Finding memory leaks (From: Alex Zavatone via Cocoa-dev <email@hidden>)
 >Re: Finding memory leaks (From: Rob Petrovec via Cocoa-dev <email@hidden>)
 >Re: Finding memory leaks (From: Alex Zavatone via Cocoa-dev <email@hidden>)

  • Prev by Date: Re: Finding memory leaks
  • Next by Date: Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads
  • Previous by thread: Re: Finding memory leaks
  • Next by thread: Re: Finding memory leaks
  • Index(es):
    • Date
    • Thread