Use Xcode and Instruments to debug iOS Memory leakage)

Although the ARC mechanism is added to iOS 5.0 and later versions, memory leakage may still exist due to the complicated mutual reference relationship. Therefore, it is important to understand the principles. This article describes how to use Instruments to find memory leaks in the program and how to use NSZombieEnabled without ARC.

This article assumes that you are familiar with the Obj-C memory management mechanism.

Development Environment of the experiment: XCode 4.5.2

1, RunDemo.

Download a Demo for Memory leakage: leak app.

Download the program and open it to run. The program is a list of all kinds of sushi rolls. I tried to select several rows in it. It should have crashed when I chose the second row. Crash:

The location where the crash is located is disconnected, but the cause of the crash is unknown.

2, SettingsNSZombieEnabled

This is an "EXC_BAD_ACCESS" error. Select NSZombieEnabled for XCode ". In crash, you may receive more prompts.

Procedure: 1

2: hook

Run the command and select the cell according to the previous operation. Crash again. This time, an error message is displayed in the output window:

13:22:08. 911 PropMemFun [2132: 11303] ***-[CFString respondsToSelector:]: message sent to deallocated instance 0x713ebc0

The message is sent to the released memory. That is to say, the released memory is used. In C, the "wild pointer" is used"

After reading the crash statement, sushiString should be okay. It is initialized from stringWithFormat. That is the problem of _ lastSushiSelected.

_ LastSushiSelected points to sushiString, which is an autorelease variable. In the second click, sushiString has been released, so crash is used. It will be retained for _ lastSushiSelected. The code is modified as follows:

1. <span style = "font-size: 14px;"> _ lastSushiSelected = [sushiString retain];

2. </span>

Run, this time does not crash.

3Analysis of Memory leakage(Shift + command + B)

If the app is no longer crash, check whether there is any memory leakage. Use XCode Analyze to Analyze where memory leakage exists.

After analysis, you can see:

The following message is displayed, indicating that alertView has not been released and memory has been leaked.

[AlertView release];

After further analysis, the problem is solved.

4, UseInstrumentsOfLeaksTools

The Analysis of Memory leakage cannot detect all memory leaks. Some memory leaks are generated only when the user operates. You need to use Instruments.

Click the above operation. After the build is successful, the Instruments tool jumps out and selects the Leaks option. At this time, the sushi program runs. After selecting the items in the list and dragging, the tool displays the following results:

As you may have guessed, the red column indicates Memory leakage. How can I see the leakage through this tool?

First, press the red circle button on the toolbar to stop the tool monitoring memory activity. Select Leak, click cross in the middle, and select Call Tree.

In this case, the options of the Call Tree in the lower left corner can be selected. Select Invert Call Tree and Hide System Libraries, which are shown as follows:

At this time, the specific code for Memory leakage is found, and the method specified in the red box on the right shows the memory leakage.

You only need to double-click these methods to jump to the specific code. Haha, isn't it very convenient.

The error 100% indicates that the memory will be leaked.

6Solve Memory leakage problems

If the problem is found, solve it.

About:TableView: didSelectRowAtIndexPathTo analyze its memory process:

1. The sushiString variable is created through autorelease. Its reference count is 1.
2. This line of code increases the reference count to 2, _ lastSushiSelected = [sushiString retain];
3. At the end of this method, the autorelease of sushiString takes effect, and the reference count of this variable is reduced to 1.
4. When the tableView: didSelectRowAtIndexPath method is re-executed, _ lastSushiSelected is assigned a new pointer. The reference count of the old _ lastSushiSelected is still 1, but it is not released, resulting in Memory leakage.

How can this problem be solved?

In _ lastSushiSelected = [sushiString retain]; previously, the original release was OK:

1. [_ lastSushiSelected release];

2. _ lastSushiSelected = [sushiString retain];

About:TableView: cellForRowAtIndexPath

This is obvious. sushiString is not released after alloc and init. You can use stringWithFormat to call autorelease. The Code is as follows:

1. NSString * sushiString = [NSString stringWithFormat: @ "% d: % @", indexPath. row, sushiName];

All right, the leaks are fixed, and you can use tools to analyze them. At this time, you can click, drag, and perform operations without memory leakage. Indicates that the memory leakage is blocked.

Reference: http://www.raywenderlich.com/This is the app Code fixed in this article: no LeakApp