This article does a great job explaining the several not really documented steps of finding memory leaks using XCode.
I do wish the XCode developers would have implemented a more intuitive UI to do the same - e.g. taking inspiration from Chrome Developer Tools, or Visual Studio.
<rant>
Actually, I would just be happy if XCode had the debugging features that Visual Studio 2005 (10 years ago) had. Like inspecting variables values with mouse over on breakpoints. Or when right clicking "refactor" in XCode on a method name, being able to refactor Swift code. 1 year after the release of Swift the error dialog "XCode can only refactor Objective C code" appears - so much for supporting the Apple's own language.
</rant>
Anyway, article bookmarked - because even after reading this, there's no way I would remember all the steps needed to debug those memory leaks!
> 7 simple and not really documented steps of finding memory leaks using XCode
There's actually event a "Leaks" template in the instruments app, I wondered why the author didn't use that. And that tool is even documented by apple, see
> It’s worth noting that the Leaks instrument can also be useful, but it is primarily used to detect memory that is never freed, not memory leaks from retain cycles.
The author does mention it.
For what it's worth, I can't see what gregdoesit quoted in the article.
That makes no sense. Retain cycles are one potential cause of memory that is never freed, and the Leaks instrument picks them up fine.
Where it fails is when memory is not freed because it's still referenced somewhere from your live objects, but shouldn't be. For example, if you keep adding subviews to a view and don't use the old ones anymore, expecting them to be destroyed but forgetting to remove them from their superview first.
Basically, Leaks is a garbage collector minus the collector, and where it fails is exactly where garbage collectors can fail and still allow leaks. Like any sensible garbage collector, it can handle cycles just fine.
(I know you just quoted it, but I thought this was a good place to address this weird aspect of the article.)
Fair point. The quote was my from the author, but my interpretation, apologies for the confusion. I've updated my comment to remove the misleading quotes.
Good article. One thing to make clear here is a memory leak is not occurring on a retain cycle. The correct terminology is abandoned memory. When memory actually isn't freed and no longer usable as there are potentially no references anymore. It has been discussed on occasion at WWDC. I believe it was in 2011, around the time they introduced ARC.
Apparently 'valgrind' is also ported to OS X, I wonder how it compares. (I haven't been able to use it yet because I'm working on a 32-bit project for an older SDK and it seems that 'valgrind' is 64-bit and using the latest system.)
But it's mostly experimental and not as easy to use as dtrace/lldb. What's more, you can't attach to the device, although there's a way to attach to the simulator — not for the faint of the heart.
I do wish the XCode developers would have implemented a more intuitive UI to do the same - e.g. taking inspiration from Chrome Developer Tools, or Visual Studio.
<rant> Actually, I would just be happy if XCode had the debugging features that Visual Studio 2005 (10 years ago) had. Like inspecting variables values with mouse over on breakpoints. Or when right clicking "refactor" in XCode on a method name, being able to refactor Swift code. 1 year after the release of Swift the error dialog "XCode can only refactor Objective C code" appears - so much for supporting the Apple's own language. </rant>
Anyway, article bookmarked - because even after reading this, there's no way I would remember all the steps needed to debug those memory leaks!