IOS Debug and release (Hoc and app Store) version crash error summary

In the course of iOS development, we often encounter inexplicable crash, and then we find it difficult to locate.
Debug version: When we encounter a exc_bad_access crash error, it is most likely because the object we are referencing is freed, or the method does not exist, and cannot be called because of a memory operation error caused by the crash. When the error cannot be located, we introduce nszombieenabled mode. When Nszombieenabled is set, an object is destroyed and converted to _nszombie, and after setting nszombieenabled, when you send a message to an object that has already been disposed of, the object will not crash or create a behavior that is incomprehensible to you. Instead, it emits an error message and then disappears in a predictable way that generates a debug breakpoint, so we can find out exactly which object is being released incorrectly. Set the nszombieenabled mode in Xcode. Click the menu bar product->scheme->edit scheme->run->argument->environment variables->+ add nszombieenabled Set to Yes to run again.

PS: Remember to remove this option when the app is published.

When we encounter signal SIGABRT and other errors, we can use breakpoints, breakpoints can be divided into conditional breakpoints and abnormal breakpoints. Breakpoints are important to help us see where the application is at a given point in time.
A conditional breakpoint, as the name implies, is a breakpoint that fires only under certain conditions:

An exception breakpoint. When we encounter abnormal situation crash, the system will generally automatically point to the main method. When we add an exception breakpoint, it will cause the problem to break again.

Release version: exception of the program when we are in the debugging phase, the above method can generally be used to navigate to the error. So how do we locate the error when we use the Release App Store version or the distribution version for an abnormal flashback?

Everyone in the project will generally join the log log, I am using the Friend League error log. When users use our app crash, the AU logs collect these error messages so that we can navigate to the wrong location via the Dysm file.

The Dysm file is generated automatically after we compile it, it is a transit file that holds the address mapping information of the 16 binary functions, and the symbol we debug is in this file. This file is important and we will save the corresponding. xcarchive file for each release. With this file, we can locate the user's information in the release, without having to pass the user's device log information. How exactly should the error message be located?
Here are the error log location errors that I use Umeng:
One step we open the Friend League error log

The address of the blue flag in the figure is the function memory address of the error. dSYM UuId We need to find our corresponding. archives file

dSYM Uuid:dwarfdumop--uuid Xx.app.dSYM

App uuid:d warfdump--uuid xx.app/xx

And the UUID in the error file put. app files and Dysm files in the same directory we can query:

Xcrun atos-arch armv7-o wherecom.app/wherecom 0x2a32f can also be queried with the Dwarfdump command

This allows us to locate the wrong function name that could be caused.

Online also have enthusiastic netizens on these commands written in the Mac tool attached, but still recommend common commands familiar with these common commands.

http://download.csdn.net/download/marujunyy/7718089

IOS Debug and release (Hoc and app Store) version crash error summary