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 > <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 _______________________________________________ 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
