Question

When profiling an app, I notice that the live bytes increases by about 250 KB every time I perform certain actions (involving UIViews).

Looking in the list of objects, the main (growing) culprit just reads as “malloc 144 bytes”.

Occasionally I have used the Allocations instrument to discover objects I have held onto longer than I would like, but I’m not sure how to interpret the “malloc” objects.

Any guidance would be greatly appreciated.

Answer 1

A couple of thoughts:

1. Allocations tool is great, but I’d focus on Leaks, first. Do you have a clean bill of health there?

2. Have you run your code through the static analyzer (“Analyze” on the “Product” menu). Especially in non-ARC code, that can identify many issues.

3. Are you using ARC? If so, that narrows the search.

4. Do you have zombies turned on? That will result in memory not being released. Make sure to turn off zombies.

5. Are you sure you don’t have a strong reference cycle (aka retain cycle)? You can put NSLog or breakpoints in your view controller’s dealloc and make sure it’s getting called and ensure you don’t have a strong reference cycle (a circular reference between two or more objects that results in neither being released). (If you don’t have a dealloc method, just add one with a NSLog statement.) Failing to invalidate a repeating NSTimer is a wonderful example of something that can inadvertently cause strong reference cycles. The key issue is that you have to confirm that dealloc is taking place.

6. Are you definitely popping/dismissing the view controller rather than pushing/presenting another copy of the other view controller? (Failure to see NSLog/breakpoint in the dealloc method can be caused by this, in addition to the strong reference cycle discussed in prior point.)

7. On your 256 (!) image views are you doing imageNamed to set the image property? The imageNamed method caches images won’t release memory until you get memory warning (though it would only consume memory when you retrieve new images, not re-retrieving existing images).

Bottom line, there can be a ton of possible issues and there’s not enough in your question to help us diagnose the problem. You have to help us narrow down the problem.

But start looking at your controllers and make sure they’re being deallocated like they should. I feel your pain about the 144 byte malloc issues, but that’s unlikely to be the culprit of consuming 250kb each time. The malloc is more likely a symptom of a problem, not the source of the problem, and I’d focus on the more basic things listed above, before spending too much time tracking down the source of the malloc calls.