Troubleshoot iOS memory leaks with Xcode and instruments debugging

Although the iOS 5.0 version number adds an arc mechanism. But because the mutual reference relationship is more complex. A memory leak may still exist.

So it is important to understand the principle.

This is described in the absence of arc. How to use instruments to find memory leaks in programs and the use of nszombieenabled settings.

This article if you are already familiar with Obj-c's memory management mechanism.

Experimental development environment: XCode 4.5.2

1, the implementation of the demo.

First download a demo that implements the prepared memory leak:

Leak app

Download down and open execution. The program is a list of sushi. List all kinds of sushi rolls. Try to choose a few lines inside. It would have been a crash when we chose the second line.

Collapse:

In the collapse of the place, know crash place, but do not know the reason for detailed crash.

2. Set nszombieenabled

This is a "exc_bad_access" error. We open the Xcode option: "Nszombieenabled".

You may be given a number of other tips when crash.

Setup steps: 1

2: Check the red box.

Execute, select the cell in the operation as you just did. Again crash, this time in the output form you will see an additional error message:

2012-11-28 13:22:08.911 propmemfun[2132:11303] * * *-[cfstring respondstoselector:]: Message sent to deallocated instance 0x713ebc0

It probably means: send a message to the freed memory. In other words, the freed memory is used, which is equivalent to using the "wild pointer" in the C language.

Look at the next crash this statement, sushistring should be no problem, it is initialized from the stringWithFormat. That's the problem with _lastsushiselected.

_lastsushiselected points to the sushistring,sushistring is a autorelease variable. On the second click. The use of sushistring has been released, so crash. Keep it for _lastsushiselected, and you'll be able to use it. Code churn such as the following:

<span style= "FONT-SIZE:14PX;" > _lastsushiselected = [sushistring retain];

</span>

Perform. This time does not crash.

3. Analyze memory leaks (SHIFT+COMMAND+B)

The app is not crash. Let's see if there's a memory leak. With Xcode's analyze, you can analyze where there's a memory leak.

After analysis, you can see:

This indicates that Alertview was not released and there was a memory leak. Then we release

[Alertview release];

Again, this problem has been overcome.

4. Using Instruments's leaks tool

The analysis of memory leaks does not reveal the full memory leaks, and some of the memory leaks occur when the user is operating at the time of execution.

Then you need to use the instruments.

Press the action above. After the build succeeds, jump out of the instruments tool and select the leaks option. At this point the sushi program also executes, selecting items in the list. After dragging and so on, the tool displays effects such as the following:

Everyone could have guessed it. The red pillar indicates a memory leak. How did you see the leak through this tool?

Press the Red Circular button on the toolbar to stop the tool monitoring memory activity.

Select Leak, then click the Middle cross to cross that, select call Tree

The option to call tree in the lower left corner is selectable. With invert call Tree and hide System Libraries selected, show demo samples such as the following:

The detailed code for the memory leak is found, and the red box on the right specifies which method has a memory leak.

You just have to double-click on these methods, you will jump to the detailed code, haha. is not very convenient.

Here should be a hint 100% memory will leak.

6. Resolve Memory leaks

The problem has been found. then solve it.

About: Tableview:didselectrowatindexpath, analyzing its memory process:

The sushistring variable is created by Autorelease. It has a reference count of 1.

This line of code causes the reference count to be added to 2. _lastsushiselected = [sushistring retain];

At the end of this approach, Sushistring's autorelease took effect. The reference count for this variable is reduced to 1

When you run Tableview:didselectrowatindexpath this method again. _lastsushiselected is assigned a new pointer, the old _lastsushiselected's reference count is still 1, not released, resulting in a memory leak.

How to solve it?

In _lastsushiselected = [sushistring retain]; Before the original release is OK:

[_lastsushiselected release];

_lastsushiselected = [sushistring retain];

About: Tableview:cellforrowatindexpath

This is more obvious, Sushistring is not released after Alloc and Init, can use stringWithFormat to invoke Autorelease, code such as the following:

nsstring *sushistring = [NSString stringwithformat:@ "%d:%@", Indexpath.row, Sushiname];  

OK, leaks are fix, and then use the tool analysis to see, this time you point, and then drag, and how to operate, there is no memory leaks.

Indicates that the memory leak is blocked.

This is the app code fixed in this article: No Leakapp

Troubleshoot iOS memory leaks with Xcode and instruments debugging