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 > <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 >> <cocoa-dev@lists.apple.com <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 >> <https://lists.apple.com/mailman/options/cocoa-dev/georg.seifert%40gmx.de> >> >> This email sent to georg.seif...@gmx.de <mailto:georg.seif...@gmx.de> > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com > <mailto: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 > <http://lists.apple.com/> > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > <https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com> > > This email sent to z...@mac.com <mailto: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
