Re: Finding memory leaks
Re: Finding memory leaks
- Subject: Re: Finding memory leaks
- From: Georg Seifert via Cocoa-dev <email@hidden>
- Date: Wed, 20 May 2020 17:08:57 +0200
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> 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
_______________________________________________
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