Before: There were a lot of articles about Leak’s tutorial. At that time, I was stuck in Step4 and couldn’t locate the memory Leaks code. Finally, I found Step5 of this article talking about dSYM files. None of the other articles mentioned it.
After compiling the project, we will see a dSYM file with the same name. DSYM is a transit file that holds the address mapping information of the hexadecimal function
There is another problem. When I was running my own demo, Cmd+I kept flashing back. The specific reason was not found out. Later on the first Cmd+R, then through the following entry will not flash back ~

Wordy finished, look at the reprinted text below ~
After iOS 5.0, Apple introduced the Xcode compiler feature ARC (Automatic Reference Counting) to help developers manage memory. However, in order to pursue high performance of APP and reduce the size of installation package, we need to manage memory manually in many cases. Even the best developers can’t guarantee that their code is 100% free of memory leaks. Memory leaks are not terrible, but terrible is that we spend a lot of time and energy, but memory leaks are still not solved, which affects our work efficiency and mood.
Let’s take a look at Instruments Leak, a memory debugger in Xcode that’s a must-have skill for ios newbie and experienced developers alike.
Nonsense less say, the following began to spread a big cake!! !
step1:
Create an ARC based test demo with the following code:
The above lines of code should be the most familiar to IOS developers as the method entry for app agent. Since we created a manual memory management project, the code line of memory leak can be located at a glance.
Step2:
To start the dynamic analysis using Leaks, click on XCode’s Product menu Profile to launch Instruments:
Click Profile Button to compile, hehe, error if you encounter
In this case, do not be nervous, first look at the error message:
MyViewController and MyNavigationController are macros I defined in a.pch precompiled file:
The problem is not with your code, but with one of the Profile compiler options:
Open the Edit Scheme option for the project
Select Profile and set Build Configuration to Debug so that the macro defined under the #ifdef Debug compilation condition takes effect in the.pch file.
Select Profile Building again, OK, Success!!
step3:
Go to the Instruments home page and select the Leak Logo
step4:
At this time the Demo program is also running, the tool display effect is as follows:
Red bars indicate memory leaks. How do you see where the leak is through this tool?
The Call Tree option in the lower right corner is now available. Select Invert Call Tree and Hide System Libraries and the following information is displayed:
The most important thing you’ll want to know is where in the project code is leaking memory. Ok, let’s locate the leaking code line.
step5:
Look at the Symbol Name column in the red box above. If you guess 0xedC00 and 0xedBda are memory addresses, you are very close to the correct answer, but it is useful for me. After compiling the Xcode project, we will see a dSYM file with the same name. DSYM is a transfer file that stores the address mapping information of the hexadecimal function. All symbols we debug will be included in this file. And a new dSYM file is generated each time the project is compiled. I’ll explain more about dSYM in a later blog post. Back to the above problem, 0xEDC00 and 0xedBda are displayed because of the problem of our project build Settings. The dSYM file is not generated, so debug Symbols cannot be resolved. Here’s how to set the dSYM option correctly:
After setting it up, re-profile build once, and the code for the memory leak is found. The red box below specifies which method is leaking memory.
step6:
Leak = Leak = Leak = Leak = Leak = Leak = Leak = Leak = Leak = Leak = Leak That means the memory leak was plugged.