Crash log symbolic and debug information

This article mainly organized the symbolic parsing of crash log and debugging information related to the configuration of some content.

For mobile app development, quality and experience are important. A client application if often "flash back", is the product quality is a poor embodiment, the user experience is not to mention. So the development of an excellent app, the first is to ensure their technical quality, as far as possible to eliminate the "flash back", that is, "Crash." However, after the client is online, occasionally a hidden deep bug is unavoidable. What we can do is to collect as much information as possible about the problem and try to solve and improve it in future releases.

0. Crash

After an app is launched, it is used to suddenly be closed by the iOS system, or simply can not get up, in the open for a moment to close, this is crash, commonly known as "flash back" "Crash."

Apps on iOS have a variety of reasons, such as overheating, response timeout, and low memory, all of which are possible crash reasons. However, in many cases, there are problems and flaws in the running logic of the app itself. For example, the call uses a method that is not supported by the Objective-c object (send message), illegal memory access, array out of bounds, parameters do not meet the requirements and so on.

During the commissioning phase, we can easily locate and resolve the breakpoints and information provided in the console.

But for published apps, if you want to reproduce and use the above approach to solve, I'm afraid it will be more time-consuming.

The most helpful and direct way is to analyze and judge the reason of crash, and quickly and accurately locate and solve the problem according to the Flash back log.

1. Crash Log

When an app running on iOS appears crash, a crash log is usually generated to document the situation when the problem occurs. Developers can find the collected crash log under specific apps in itunes Connect (equivalent to the App Store backend). However, the client user can choose not to send diagnostic information, so the collected information is not necessarily comprehensive.

However, developers can set custom handler for exception and signal to do additional processing to collect field information. Now there are a lot of third-party tools are very popular, such as Crashlytics, domestic friends of the league and so on.

The Flash log contains the app crash, the running hardware and software environment, the time of occurrence, the type of error, the method call exception stack, the thread state, register, and memory information.

And one of the most significant things for our developers is probably the call stack for the exception thread, for example:

1 Last Exception backtrace:2 0Corefoundation0x18517e950__exceptionpreprocess + the3 1LIBOBJC. A.dylib0X1916841FCObjc_exception_throw + -4 2Corefoundation0x185085910-[__nsdictionarym Setobject:forkey:] + the5 3Crashdebuginfotest0x1000c2b90 0x1000bc000+275366 4Crashdebuginfotest0X1000C28DC 0x1000bc000+268447 5UIKit0x1881bc55c-[uiapplication _handledelegatecallbackswithoptions:issuspended:restorestate:] + the8 6UIKit0x1881bbf08-[uiapplication _callinitializationdelegatesforurl:payload:suspended:] +15649 7UIKit0x1881b59ec-[uiapplication _runwithurl:payload:launchorientation:statusbarstyle:statusbarhidden:] +772Ten 8UIKit0x1881498cc-[uiapplication Handleevent:withnewevent:] +3316 One 9UIKit0x188148ad0-[uiapplication Sendevent:] +104 A TenUIKit0x1881b5044_uiapplicationhandleevent +672 -  OneGraphicsservices0x18ad63504_purpleeventcallback +676 -  AGraphicsservices0x18ad63030Purpleeventcallback + - the  -Corefoundation0x18513e890__cfrunloop_is_calling_out_to_a_source1_perform_function__ + About -  -Corefoundation0x18513e7f0__cfrunloopdosource1 +444 -  theCorefoundation0x18513ca14__cfrunlooprun +1620 -  -Corefoundation0x18507d6d0Cfrunlooprunspecific +452 +  -UIKit0x1881b41c8-[uiapplication _run] +784 -  -UIKit0X1881AEFDCUiapplicationmain +1156 +  +Crashdebuginfotest0x1000c2c5c 0x1000bc000+27740 A  -Libdyld.dylib0x191c77aa0Start +4

View Code

From the second column, many are calls in the development library, and the key lies in our own app method calls. Unfortunately, in some cases, this key information is all 16 data, we are very difficult to read. Like what:

1 3 0x1000c2b90 0x1000bc000 27536

In order to get the corresponding method call in our code from the 16 binary address code, we need to symbolize the crash log with debug information.

2. Symbolization of the various methods

There are a variety of symbolic methods, from online community forums and personal experience, at least as follows:

• Using the Symbolicatecrash that comes with the Dev tool Library

• Using Atos

• Using Dwarfdump

More cattle, wrote a complex script to solve the problem. Let me introduce the two methods I use frequently, one is to use Atos, and the other is to take advantage of the tools that are available from Xcode. Other people can go to the Internet to see related articles, a search a large basket.

Atos, the address to symbol, translates addresses into symbols. The above paragraph I mentioned, in order to translate the hexadecimal address into a symbol, need debugging information. The best debugging information is the dSYM file we generate each time we package the app. The best way to use Atos is to:

1	atos -o XXX.app.dSYM/Contents/Resources/DWARF/XXX -l address0 targetAddress

which

• XXX is appname

• ADDRESS0 is the starting address for the current process to load in memory, and as for why this is needed, it is necessary to understand the following ASLR

• TargetAddress is the address you want to symbolize, like 0x1000c2b90.

In addition to Atos, another way I would like to introduce is to use the Crash Log analysis tool that comes with Xcode, in the old version of Xcode in organizer, in the new version is in devices.

Some friends may say that the inside of the display can still be the hexadecimal address ah! That's because it "didn't see" apps and dSYM files. So what? Simple:

Put the app and dSYM in a directory, and use Mdimport to add the directory to the spotlight index.

How about this trick is not faster and better use? Symbolicatecrash God horse will not need it!

3. Crash positioning and debugging options settings for the framework static library

I've developed a lot of SDKs for others in the framework (IOS Universal framework). The app's name is also displayed in the exception stack when an app that uses the framework library is flashed back, even if it's a logic problem in the SDK.

More importantly, by default, the right-most column of the exception stack cannot be symbolized at all.

This is because the framework is actually a static library that, when the build app is fully "integrated", is statically linked to the app product. When the framework is generated, the debug information has been pulled out.

We open the project file of the SDK and search for strip in build settings, we will find several options:

• Strip Debug Symbol During Copy

• Strip Linked Product

• Strip Style

• Use separate Strip

For this problem, we just have to select No in the Strip Linked product item. This will make the package larger in the build-out SDK framework because it holds the debug information to be removed.

According to my previous blog approach, let's look at what's more in the Mach-o file:

Debug Info

Yes, it is the data in dwarf format. Dwarf is a generic debug information format that can be considered an abbreviation for debugging with attributed Records format. Interested can go to: http://www.dwarfstd.org

Crash log symbolic and debug information