
Finding iOS Memory Leaks with Xcode's Instruments - philk10
https://spin.atomicobject.com/2016/01/25/ios-memory-leak-xcode/#.VqaGcF_w1AE.hackernews
======
gregdoesit
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!

~~~
derwildemomo
> 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

[https://developer.apple.com/library/ios/documentation/Develo...](https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/FindingLeakedMemory.html)

~~~
bestows
> 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.

~~~
mikeash
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.)

------
thearn4
I had pretty good luck using Instruments -> Leaks to find a leak in an OS X
spritekit app (swift) I was making a few months ago.

I just wish I didn't have to hack and guess my way around spritekit to fix
it...

~~~
seivan
What part of SpriteKit was leaking?

------
ronnyf
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.

------
makecheck
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.)

~~~
Arcanum-XIII
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.

