IOS Crash Log parsing

iOS development, often encountered in the development and testing of the app will not be a problem, but installed in other people's devices will be a variety of occasional inexplicable crash, because the iOS device will save most of the app's crash log, so you can crash log to locate crash reason.

I. Get crash log on your iOS device

1. Connect your iOS device to your computer, open Xcode---Organizer, Devices, locate the device, and in device logs, locate the crash log (the. Crash log file) and export it.

2. If your app is already on the app Store, developers can get a user's Reports log via itunes Connect (Manage Your applications-view details-crash Crash). However, this is not 100% effective, and most developers do not rely on this, as this requires the user device to agree to upload relevant information, see Ios:providing Apple with Diagnostics and usage information summary.

Two. parsing iOS crash log

The information obtained in the crash log is a 16-binary memory address and cannot locate the crashed code, so the 16-in memory address needs to be parsed into the corresponding class and method.

Parsing the crash log requires the use of the. App and. Sysm two files that are sent when the app is uploaded (so you can save these two files each time you upload a new version, or you won't be able to parse crash log) to copy the. App. Dysm and crash log files to the same folder so Use Symbolicatecrash to parse.

Get. App and. dysm files: In iOS development, you need to generate. xcarchiver files using Xcode packaging, which can be managed in Xcode-> Organizer-> Archive and exported accordingly. Xcarchiver The. xcarchiver file contains the. app and. dysm files.

Symbolicatecrash is a hidden file and is independent of Xcode, located in:/applications/xcode.app/contents/developer/platforms/iphoneos.platform/ Developer/library/privateframeworks/dtdevicekitbase.framework/versions/a/resources/symbolicatecrash

Before parsing with Symbolicatecrash, check the. App. Dysm and crash log three files The UUID is the same, only three of them can be parsed. See the UUID methods for three files as follows:

1. To view the UUID method of the Xx.app file, enter it in Terminal.app:

$ dwarfdump--uuid xxx.app/xxx (XXX project name)

2. To view the UUID method of the Xx.app.dSYM file, enter it at the command line:

$ dwarfdump--uuid Xxx.app.dSYM (XXX project name)

3. How to view the UUID of the crash log file:

In the crash log file, find the Binary Images: A string in the first angle bracket after the project name is the UUID of the crash log file.

Use Symbolicatecrash to parse:

Enter the following command in the Terminal.app:

$./symbolicatecrash Xxx.crash Xxx.app.dSYM > Test.log

The command parses the crash file into a test.log file, and Test.log is a readable function file.

Typing the above command may cause error: "Developer_dir" is not defined at./symbolicatecrash Line 53. This error.

If the above error occurs, enter the command: Export Developer_dir=/applications/xcode.app/contents/developer,

Then continue execution./symbolicatecrash Xxx.crash Xxx.app.dSYM > Test.log can be successful

Three. Other parsing (based on address resolution):

Parse the contents of an address

Method One:

$ xcrun atos-o xxx.app/xxx-arch armv7 0x38ad42f9 0x38ad42f9 0x38ad42f9 (multiple 16-input addresses, separated by spaces)

Method Two:

$ dwarfdump-–lookup 0x000036d2-–arch armv6 Xxx.app.dSYM

If you follow the above two methods, you are prompted to find an address, you can use method three:

Method Three:

Find the address that corresponds to the following:

(Current line of code address = Current address + address offset, address offset is decimal value)

Ten testtransform 0x00057132 0x4f000 + 33074

1. First a simpler way to take advantage of "current address" and "Current code line address"

$ xcrun atos-o testtransform.app/testtransform-arch armv7 0x3d000 0x0004fc5c

Output Result:

Bddemacbook-pro:1 baidu$ xcrun atos-o/users/baidu/desktop/1/testtransform.app/testtransform-l 0x3d000 0x0004fc5c

Got Symbolicator For/users/baidu/desktop/1/testtransform.app/testtransform, base address 4000

Main (in Testtransform) (main.m:16)

2. The second relatively complex point, involving the offset of the address, first look at the start address, even if each iOS app boot will load (main module) The main module in different memory address, but the dSYM file assumes that your main module is loaded at address 0x1000 (in most cases this, also 0x4000).

How to get this address:

$ Otool-arch Armv7-l/users/cnstar-tech/crash/xxx.app/xxx | Grep-b 1-a "Lc_segm" | Grep-b 3-a 8 "__text"

Call the above method to return the result as follows:

Load Command 1

CMD lc_segment

Cmdsize 600

Segname __text

Vmaddr 0x00004000

Vmsize 0x00014000

Fileoff 0

FileSize 81920

Maxprot 0x00000005

Initprot 0x00000005

Nsects 8

Flags 0x0

See vmaddr shown as 0x00004000.

Then view "Testtransform 0x00057132 0x4f000 + 33074" using the start address + address offset as:

0x4000 + 33074 = 0xc132 (Note: The preceding is 16 binary followed by the 10 binary addition, to be converted to 10 binary addition, the results are converted to 16 binary)

You can use the "0xc132" address to view the content:

Method One:

$ dwarfdump--lookup 0xc132--arch armv7 TestTransform.app.DSYM

Output Result:

----------------------------------------------------------------------

File:testtransform.app.dsym/contents/resources/dwarf/testtransform (ARMV7)

----------------------------------------------------------------------

Looking up address:0x000000000000c132 in. Debug_info ... found!

0x00003947:compile unit:length = 0x00007b6e Version = 0x0002 Abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0 X0000B4B9)

0x00003952:tag_compile_unit [1] *

At_producer ("Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)")

At_language (DW_LANG_OBJC)

At_name ("/USERS/BAIDU/DESKTOP/TESTTRANSFORM/TESTTRANSFORM/VIEWCONTROLLER.M")

AT_LOW_PC (0x0000a950)

At_stmt_list (0x0000089f)

At_comp_dir ("/users/baidu/desktop/testtransform")

At_apple_major_runtime_vers (0x02)

0x00003c22:tag_subprogram [39] *

At_name ("__29-[viewcontroller aaaaaaaaaa:]_block_invoke")

At_decl_file ("/USERS/BAIDU/DESKTOP/TESTTRANSFORM/TESTTRANSFORM/VIEWCONTROLLER.M")

At_decl_line (191)

At_prototyped (0x01)

At_apple_isa (0x01)

At_accessibility (Dw_access_public)

AT_LOW_PC (0x0000c09c)

AT_HIGH_PC (0x0000c182)

At_frame_base (R7)

0x00003c46:tag_lexical_block [34] *

AT_LOW_PC (0X0000C0D6)

AT_HIGH_PC (0x0000c17e)

Line table dir: '/users/baidu/desktop/testtransform/testtransform '

Line table file: ' viewcontroller.m ' line 193, column 0 with start address 0x000000000000c11e

Looking up address:0x000000000000c132 in. Debug_frame ... found!

0x00000160:fde

length:0x0000000c

cie_pointer:0x00000000

start_addr:0x0000c09c __29-[viewcontroller Aaaaaaaaaa:]_block_invoke

Range_size:0x000000e6 (end_addr = 0x0000c182)

instructions:0x0000c09c:cfa=4294967295+4294967295

Method Two:

$ xcrun atos-o/users/baidu/desktop/1/testtransform.app/testtransform 0xc132

Output Result:

__29-[viewcontroller Aaaaaaaaaa:]_block_invoke (in Testtransform) (viewcontroller.m:193)

Four. How to determine the crash of two crash log files is the same reason:

1. You can compare triggered by thread to see if it is the same thread, not the same reason.

2. If there is a last Exception backtrace, you can compare the last Exception backtrace address in the number of rows, the number of different reasons, the number of rows if the same can be two last Exception BackTrace address A comparison, (generally the first few lines and the last few lines are called system functions, so the address is the same), until the first occurrence of a different address, you can use Dwarfdump to resolve the two addresses, if the resolution of the method is different, then the crash reason is different.

Five. Organizer automatic parsing in Xcode:

If the project is packaged on your own machine, you can connect your iOS device to your computer so that the crash log in the device is automatically parsed by organizer and, if not automatically parsed, you can right-click the crash log selection re-symbolicate. (The reason why organizer can be resolved automatically is that it is built when it is packaged.) The index of the app and. Dysm two files, so you can automatically parse the crash log file)

You can also manually index the app's. App and. Dysm two files into the same folder, and then manually index it with the Midimport foldername command, then import the crash log file into Xcode Organizer , automatic parsing is performed. (Can bulk import crash log file, batch parsing)

Six. Use the dedicated Crash Log parsing tool for parsing:

such as Quincykit, Crashlytics, flurry and so on.

IOS Crash Log parsing