• 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: Alex Zavatone via Cocoa-dev <email@hidden>
  • Date: Wed, 20 May 2020 10:16:33 -0500

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

  • Follow-Ups:
    • Re: Finding memory leaks
      • From: Rob Petrovec via Cocoa-dev <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>)

  • Prev by Date: Re: Finding memory leaks
  • Next by Date: Re: Finding memory leaks
  • Previous by thread: Re: Finding memory leaks
  • Next by thread: Re: Finding memory leaks
  • Index(es):
    • Date
    • Thread