iOS Performance Tuning series: Dynamically analyze Zombie objects in memory using zombies

Hard Canton: "iOS Performance Tuning Series" fourth, is expected to be more than 20, continuously updated, welcome attention.

Top two iOS Performance Tuning series: Analyze static Analysis, iOS Performance Tuning series: using instruments to dynamically analyze memory leaks focuses on memory leaks, the opposite of which is focused on objects that are over-disposed in memory (overreleased objects).

The title of this article tangled for a long, in the end is to write exc_bad_access error debugging, or write memory zombie object analysis, and finally chose a duang~duang~ title.

Today in the forum to see a post, encountered is this article to analyze the problem, just take to explain the bug scene:

believe that before using arc, many people have encountered exc_bad_access error, this error can be understood as access to the object has been released, Apple called the Zombie object.

For example, without opening the arc, the following code:

nsstring* Hello = [nsstring stringwithformat:@ "Hello"]; NSLog (@ "What are say is%@", hello);  

The Hello object is not assigned manually, but is added to the auto-release pool, which is freed by the release pool, so the third row calls release and generates a exc_bad_access error.

After the arc is turned on, you can largely avoid exc_bad_access errors, but there are also possible, such as the use of C + + code in iOS, C + + parts of the object will not have arc to manage.

Exc_bad_access errors are not as easy to locate as a null pointer, and it is often difficult to find the wrong point when an error occurs, so Xcode provides a separate zombies tool to analyze such errors in instruments.

The principle of using zombies analysis

As with other tools that use instruments, click the Xcode Product menu profile to start instruments:

You can see the description below the Zombies tool to find those zombie objects that have been over-disposed.

The Zombies tool's lookup principle is the same as setting the NSZOMBIEENABLED environment variable, and the nszombieenabled is set to true internally after starting zombies.

With nszombieenabled enabled, it replaces the default Dealloc implementation with a zombie, which translates the object into a Zombie object when the reference count drops to 0 o'clock. The role of a zombie object is that when you send a message to it, you do not crash or create an incomprehensible behavior, but instead emit an error message that displays a log and automatically jumps into the debugger, so we can find the specific or presumably which object was released incorrectly.

Steps for using zombies analysis

1, start instruments, choose Zombies;

2. Rerun the test case that generated exc_bad_access until the program crashes, and if a exc_bad_access error occurs, the following interface appears:

3, through the sliding arrows to view the error details, such as can see the object's memory operation process, such as malloc, Autorelease, retain, release and other operations;

4. To view the detailed history at the bottom, select the appropriate line to navigate to the code to find the code that generated the error:

Basically, it is easier to find the error code line by looking at the information given by the Zombies tool, and zombies is only useful if the exc_bad_access error is generated.

To set the nszombieenabled environment variable manually:

Xcode also provides a way to manually set the nszombieenabled environment variable, but setting Nszombieenabled to true causes memory consumption to grow and affects the debugging of the leaks tool. This is because setting nszombieenabled uses zombie objects instead of freed objects.

Click the Product menu, edit scheme to open the page, and then tick the Enable Zombie Objects check box:

Manual setup is generally not recommended and should be debugged using the Zombies tool.

Record, for the better of myself! Reprint please specify the source!

iOS Performance Tuning series: Dynamically analyze Zombie objects in memory using zombies