Re: Finding memory leaks

[Rob Petrovec via Cocoa-dev]

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  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/mavOyOT 
> https://imgur.com/3mnRUa1 
> 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 > > 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 
>>> mailto:cocoa-dev@lists.apple.com>> 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 
 mailto:cocoa-dev@lists.apple.com>> 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 
> mailto:cocoa-dev@lists.apple.com> 
> >> 
> 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?
> 

Re: Finding memory leaks

[Alex Zavatone via Cocoa-dev]

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/mavOyOT 
https://imgur.com/3mnRUa1 
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  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 
>>  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 
>>>  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 
 mailto:cocoa-dev@lists.apple.com>> 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 

Re: Finding memory leaks

[Jens Alfke via Cocoa-dev]

> On May 20, 2020, at 7:03 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> This line is in a method I declared like that:
> 
> - (void) loadNextImageWithIndex: (unsigned long) next_index image: 
> (CGImageRef *) next_image
>  withProps: (CFDictionaryRef *) next_props

Off-topic, but that's an odd signature. Wouldn't it be clearer to return the 
CFDictionaryRef instead of making it an 'out' parameter?

> The caller then makes a copy of next_props for later use, and CFRelease's 
> next_props.
> (That copy is also released later.)

The "copy" may be the same object. In CoreFoundation and Foundation, if you 
copy an immutable object, you just get back a new reference to the same object. 
Same effect, but it saves memory and time. So the leaky code may be in 
whatever's managing that copy you made.

> So it is unclear to me why the Leaks tool thinks that the above line leaks 
> memory.

Leaks can be hard to track down; I sympathize.

Avoiding CF objects as much as possible helps. Recall that an NSDictionary* is 
the same as a CFDictionaryRef. You can use bridge casts to convert, and if the 
CF ref needs to be released later, you can call CFBridgingRelease which casts 
and autoreleases in one operation.

Another useful but not-well-known function is CFAutorelease, which is the 
equivalent of pre-ARC Obj-C `autorelease`. You basically call it instead of 
CFRelease; but you can call it immediately and keep using the object, because 
autorelease just promises that the object will be released sometime later.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Finding memory leaks

[Rob Petrovec via Cocoa-dev]

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 
>  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 
>>  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 
>>> mailto:cocoa-dev@lists.apple.com>> 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 

Re: Finding memory leaks

[Alex Zavatone via Cocoa-dev]

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 
>  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 
>> mailto:cocoa-dev@lists.apple.com>> 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 (Cocoa-dev@lists.apple.com)
>> 
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/georg.seifert%40gmx.de 
>> 
>> 
>> This email sent to georg.seif...@gmx.de 
> 
> 

Re: Finding memory leaks

[Alex Zavatone via Cocoa-dev]

Do NOT use Instruments.  

Use the Memory Graph Debugger.  It’s in your debugger console near the 
breakpoint button and View Hierarchy Debugger.

Try that first.  

> On May 20, 2020, at 9:03 AM, Gabriel Zachmann via Cocoa-dev 
>  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 (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Finding memory leaks

[Georg Seifert via Cocoa-dev]

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 
>  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 (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/georg.seifert%40gmx.de
> 
> This email sent to georg.seif...@gmx.de

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Finding memory leaks

[Gabriel Zachmann via Cocoa-dev]

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.





smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com