3

I just started learning the instruments tool, and I'm pretty sure what I am seeing is not good. When I look at allocations, specifically the column "Live Bytes" and "Overall Bytes", I see the number continually increases as the app runs...

My app has two view controllers. A table view, and the second view controller displays detailed information about the row they selected in the table view, downloaded from the internet.

I kept clicking a row in the table view, followed by clicking the back button in the navigation bar... and LiveBytes continued to increase.

I'm guessing this means that my objects aren't being released from memory... but please correct me if I'm wrong.

MY QUESTION IS: How do I use the data in instruments/allocations to track down this memory issue? How do I find the objects not being released from memory?

I'm looking for tips on how to use these tools to clean up any memory problems my app has.

Thanks!

XCODE 4.2.1, deploying to iOS 5.0+

EDIT: I'm looking at the #living column and seeing objects like UIScrollView continuously increase... and never decrease. When I click the back button in a navigation bar, are objects automatically released from memory? When are objects released, or do I need to do it manually? Or could I be running into an issue due to using strong pointers, causing objects to not be released?

user1467188
  • 617
  • 1
  • 10
  • 28
  • It sounds like you're asking how to track down a memory leak. For that, there is a special tool in instruments called "Leaks." Note that there is a difference between leaking memory and reusing objects to keep overall allocations down. – isaac Jul 17 '12 at 18:36

4 Answers4

1

Whenever you want to observe memory usage in a cyclic pattern, there's the wonderful Heapshot analysis in the "Allocations" instrument.

  1. Start your app and go to a default state.
  2. In Instruments, press the "Mark Heap" button to create the "Baseline".
  3. Do something in your app like pushing a view controller.
  4. Return to the default state.
  5. Press the "Mark Heap" button again to create a heapshot.
  6. Repeat about five times from step 3.

This will result in a list of heapshots, each showing the objects that are still alive from that cycle. If your app has no leaks there will be no objects left in the middle heapshots.

The first one or two cycles might have warmed up some caches, the last two might not have cleaned up some reused resources. That's why it's usually a good idea to make four to six heapshots.

The magic in the heapshot analysis lies in the fact that the heapshots show you the leaked objects from previous cycles and remove them automatically when the objects are released later. In contrary to the "Leaks" instrument it also finds abandoned memory, not only leaks.

Nikolai Ruhe
  • 81,520
  • 17
  • 180
  • 200
1

Most Probably you have discarded the arm64 and are running your app with armv7 only. Add both arm64 and armv7 as architectures

Faruk Hossen
  • 185
  • 1
  • 8
0

I think one of the best ways to solve memory issues is to use ARC. 

Edit -> Refactor -> Upgrade to Objective-C ARC.

ARC will handle the majority of memory management in your app. Especially sice your app doesn't sound too complex, it might totally eliminate your problem. You still need to watch out for retain cycles and listen to memory warnings though. If you don't want to use ARC (which you should) at least run the static analyzer. Your problem might be something simple that the static analyzer can show you how to fix.

Edit:

You mentioned scroll views- this might be your problem: Memory leak every time UIScrollView is released

Community
  • 1
  • 1
eric.mitchell
  • 8,817
  • 12
  • 54
  • 92
0

The profile tool has an instrument called 'Leaks'. It is similar to the 'Allocations' instrument but it shows you the object that was not released. May be you can use the 'Leaks' tool to find what is the object that was retained and release these object.

HernanD
  • 11
  • 2