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 <z...@mac.com> 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/Pq0eEkf> > https://imgur.com/mavOyOT <https://imgur.com/mavOyOT> > https://imgur.com/3mnRUa1 <https://imgur.com/3mnRUa1> > https://imgur.com/4nksFco <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 <petr...@mac.com >> <mailto:petr...@mac.com>> 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 >>> <cocoa-dev@lists.apple.com <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 >>>> <cocoa-dev@lists.apple.com <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 >>>>> <cocoa-dev@lists.apple.com <mailto:cocoa-dev@lists.apple.com> >>>>> <mailto: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 >>>>> <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/georg.seifert%40gmx.de >>>>> <https://lists.apple.com/mailman/options/cocoa-dev/georg.seifert%40gmx.de> >>>>> >>>>> <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> >>>>> <mailto:georg.seif...@gmx.de <mailto:georg.seif...@gmx.de>> >>>> >>>> _______________________________________________ >>>> >>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com >>>> <mailto:Cocoa-dev@lists.apple.com> <mailto: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/> <http://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> >>>> <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> <mailto:z...@mac.com >>>> <mailto:z...@mac.com>> >>> _______________________________________________ >>> >>> 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/petrock%40mac.com >>> <https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com> >>> >>> This email sent to petr...@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
