0

I am creating an iPhone app. Running into memory issues I started using Instruments to track down any memory problems. Am running into some strange behavior that leads me to believe that I am either mis-using Instruments or mis-reading its data.

These are the LiveBytes values recorded when moving in and out of a location:

**Expensive Location-**
World (12 MB)
Loc (27 MB)
World (13 MB )
Loc (28 MB)
World (14 MB)
-Crash

**Cheap Location-**
World (12 MB)
Loc (23 MB)
World (13 MB )
Loc (24 MB)
World (14 MB)
-Crash

Notice how I still crash even though the cheap location's memory has come no where near the expensive locations memory. Could anyone help me out here?

TurqMage
  • 3,321
  • 2
  • 31
  • 52
  • I'm confused - what's a cheap location or an expensive location in this context? – Rup May 12 '11 at 17:33
  • An expensive location uses a lot of memory, a cheap location doesn't use as much. – TurqMage May 12 '11 at 17:42
  • 1
    What does the amount of memory usage have to do with crashing? What's the crash? You're almost certainly over-releasing something (that being the #1 cause of iOS crashes). – Rob Napier May 12 '11 at 17:46
  • When running through Xcode the program closes and the console reads "Program received signal: “0”." After reading around it sounded like the problem was memory related (http://stackoverflow.com/questions/4149916/iphone-ipad-the-dreaded-program-received-signal-0). So to debug I didn't load any textures and the program ran fine. So now I am trying to figure out how much I can load. – TurqMage May 12 '11 at 18:01

1 Answers1

1

I'm not sure if this is related to the problem you have but I hope it helps: I was recently tracking the memory footprint of an app and I noticed that even though the dealloc message was being sent to a view controller after hitting "back" on the UINavigator controller, I still had a few dozen live objects left over from this operation (you can see this in the 'Allocations' panel of the instruments app). To solve this I used a mix of a few things:

First, I added the following three methods to NSLog the retain counters of my Custom subviews (found here on SO at iOS4 - fast context switching):

#pragma mark - RETAIN DEBUG MAGIC
// -----------------------------------------------------------------------------

- (id)retain
{
  NSLog(@"retain \t%s \tretainCount: %i", __PRETTY_FUNCTION__ , [self retainCount]);
  return [super retain];
}
- (void)release
{
  NSLog(@"release \t%s \tretainCount: %i", __PRETTY_FUNCTION__ , [self retainCount]);
  [super release];
}
- (id)autorelease
{
  NSLog(@"autorelease \t%s \tretainCount: %i", __PRETTY_FUNCTION__ , [self retainCount]);
  return [super autorelease];
}

Then, I isolated each one of the view building blocks leaving only one simple task (for example loading a UIButton as a subview) and went back to the instruments app to track the live objects (under Product > Profile in Xcode) and disabled all the objects with 'NS', 'CF' and 'Malloc' prefixes (you can do this clicking on the little i button next to the 'Allocations' tab). After this, selected "Call Trees" on the bottom right pane and kept drilling until I found a few places where the object counter went up as I navigated back and forth.

Notice that you can double click on the symbol to see the details related to the calls made to the processor. Additionally, clicking on the little i icon will bring a pop up with the backtraces for the highlighted call.

When looking at the backtraces you will see that some of them have a small icon that depicts a person on a frame (the text next to these icons is significantly darker as a visual cue). Double clicking on these will take you to the line in your code responsible for this call.

Below are a few links that might give you a hand in understanding more about instruments:

Note: At the end of my journey, all I had to do was release my views after adding them to their 'super' views to ensure they would be dealloc'd. i.e.,

[[self view] addSubView:aButton];
[aButton release];
Community
  • 1
  • 1
Edgar
  • 76
  • 3