How does xcode analyze and detect memory leakage (iOS) and xcodeios?

How does xcode analyze and detect memory leakage (iOS) and xcodeios?

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.

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:

1	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	_ LastSushiSelected = [sushiString retain];

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.

1	[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: didSelectRowAtIndexPath, analyze its memory process:

• The sushiString variable is created through autorelease. Its reference count is 1.
• This line of code increases the reference count to 2, _ lastSushiSelected = [sushiString retain];
• At the end of this method, the autorelease of sushiString takes effect, and the reference count of this variable is reduced to 1.
• 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 2	[_ LastSushiSelected release]; _ 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.

Above Original article link: http://www.cocoachina.com/ios/20141203/10519.html

Of course, even if you set all of the above, some memory leaks may not be detected. You can place the code in the debug mode in the class where you predict that memory leaks may occur, the following is the target: respondsToSelector is release and cannot be located.

# Ifdef _ FOR_DEBUG _

-(BOOL) respondsToSelector :( SEL) aSelector {

Printf ("SELECTOR: % s \ n", [NSStringFromSelector (aSelector) UTF8String]);

Return [super respondsToSelector: aSelector];

}

 

# Endif