Memory Graph Debugger Tips

I’ve been using Xcode’s new memory graph debugger for just about a day, so I don’t have a ton to share here, but I do have a few things.

• To start, hit the rotated Sleestak-fingers button in the debugger. It’s between the Cyberman button (view debugger) and paper airplane (location simulator). In other words: it’s not in Instruments. It’s in Xcode.

• Turn off zombies. If your scheme has zombies on, you’re going to get a bunch of extra noise. (Tip: keep zombies off in general until you need them.)

• Turn on Malloc Stack Logging in Diagnostics in your scheme. (I think I have it right that this needs to be on in order for the memory graph debugger to show backtraces.)

• Open the right-hand sidebar in Xcode. Clicking on an object shows its class, hierarchy, and backtrace.

• Lines between objects have a label. A line represents a reference. Click on the label to see if the reference is strong or weak or unknown and what the source and destination are.

• Don’t click on anything where the name looks something like MagicOb (something like that). It crashes Xcode for me every time.

• Click on the circle-with-double-arrows to expand a tree. To unexpand, click again in that same spot. (The arrows point inward now instead of outward.) However, there’s a bug where sometimes this disappears. Select something else in the left-hand sidebar and then come back, and the collapse arrows should appear.

• In the left-hand sidebar, look for the purple icon with the ! inside. These indicate possible problems.

• However, most problems aren’t detected. It’s up to you go through and see what’s hanging around that should not be.

I’ve fixed two bugs using the memory graph debugger, and I saved a bunch of time in both occasions. It’s probably worth telling about them as a reminder of the kinds of problems you can run into.

Notification block

An NSNotification observer was set up using a block — which is something I myself don’t do, since it litters an init or viewDidLoad with extraneous code and since it’s dangerous.

It’s dangerous because, unless you remember to be careful, it can capture a strong reference to self, and then that object is never going to go away. I don’t like APIs that require the developer to remember extra things like this.

And, sure enough, this was one of those cases.

The tipoff was in the memory graph debugger: the reference was labelled as “capture,” which let me know there was a block doing a capture, and it was then pretty quick to find out where.

(See also, from 2015: How Not to Crash #3: NSNotification.)

View controller / view retain cycle

There’s a general rule of programming that says objects should know about their children but not about their parents.

However, sometimes a view needs to know about its view controller. This is less than ideal, but sometimes it’s the least-bad option. (Well… I’m skeptical — but it happens, and we ship great apps, so there ya go.)

The related rule of programming says that if a child knows about its parent, it still can’t hold a strong reference to its parent.

That’s what was happening here: a view was retaining its view controller. The simple fix was to make that a weak property.

And, again, the memory graph debugger took me right to this. I could see what was happening inside the app in a way I never could before.

It’s marvelous. You should use it.