Re: Finding memory leaks
Re: Finding memory leaks
- Subject: Re: Finding memory leaks
- From: Rob Petrovec via Cocoa-dev <email@hidden>
- Date: Wed, 20 May 2020 13:58:08 -0600
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> 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> 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>> 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)
>>>
>>> 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 <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 <mailto: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
_______________________________________________
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