IOS Crash Log Analysis

On the shelves Appstroe was called back because of:

Your app crashed on the IPad running IOS 11.3.1 connected to a IPV6 network when we tapped the profile image.

We have attached detailed crash logs to help troubleshoot this issue.

Crash log

I. Structure of the crash file

When the program runs crash, the system will record the running information of the last moment of the run and store it in a file, which is what we call the crash file. iOS crash logs are usually made up of the following 6 parts.

1. Process information (Progress information)

Incident Idnetifier	Unique identifier of the crash report, different crash
Crashreporter Key	The unique key value corresponding to the device ID (not the udid of the real device, which Apple has not been able to secure in order to protect the user's privacy iOS6). This value is usually the same when the same version of the app on the same device occurs crash.
Hardware Model	Represents the type of device in which the crash occurred, and "ipad4,4" represents the ipad Air
Process	The process name that represents crash, usually the name of our app, [] which is the ID of the process at that time.
Path	Executable program on the phone storage location, note the path to Xxx.app/xxx,xxx.app is actually as a bundle, the real executable is actually the bundle inside of XXX, interested can check the relevant information on their own, have the opportunity I will also introduce to
Identifier	Your app's indentifier, usually "com.xxx.yyy", XXX represents your company's domain name, yyy represents an app
Version	The version number of the current app, consisting of two fields in Info.plist, and CFBundleShortVersionStringCFBundleVersion
Code Type	CPU architecture of the current app
Parent Process	The parent process of the current process, since iOS apps are usually single-process, the general parent process is LAUNCHD

2. Basic Information

Date/time	Crash occurrence of time, readable string
OS Version	The number in the system version, () represents the time Bulid number
Report Version	Crash log format, is basically 104, different version contains the fields may have different

3, Exception (very important)

Exception Type	Exception type
Exception Subtype:	Exception subtype
Crashed Thread	The thread number in which the exception occurred

4. Thread BackTrace

The crash call stack of the thread that occurs crash, from top to bottom, represents the order of the calls, the top one represents the location where the exception is thrown, and in turn you can see the order in which the API is called. The information indicates that this time crash appears Xxxviewcontroller 323 rows, the function call of the error is ordercountloadfailed.

5. Thread State

Crash time occurs, the state of the thread, usually we can get the relevant information according to the crash stack, this part of the general do not care.

6, Binary Images

Crash moment app loads all the libraries, where the first line is the information of our app executable when crash occurs, can be seen as ARMV7, the package of the executable file is the UUID bit c0f......cd65, When parsing crash, the UUID of the dSYM file must be the same as this to complete the symbolic parsing of the crash.

Ii. Common types of crash

1. Watchdog Timeout

Exception code:0x8badf00d, not very intuitive, can be read as "Eat bad food", meaning that don ' t block main thread

Next there is a description:

Application Specific information:

Com.xxx.yyy failed to resume in time

For this type of crash, we should look at the correct things to do when the app is initialized, whether the main thread requests the network, or other time-consuming things that are stuck in the normal initialization process.

Usually the system allows an app to boot up to a maximum of 5 s for the user event, and if it exceeds the 5s,app it will be terminated by the system. There will be a corresponding time requirement when launch,resume,suspend,quit. In the highlight thread we can see where it was called when it was terminated, Xxxappdelegate plus the line number.

PS. In order to facilitate debugging when connecting Xcode debugging, the system temporarily disables watchdog, so the discovery of such problems requires the use of a normal startup mode.

2. User Force-quit

Exception Codes:0xdeadfa11, Deadfall

This forced exit with what we usually say kill the background task operation is not quite the same, usually in the program bug caused the system can not respond to use long press the Power key, when the screen appears when the Shutdown Confirmation screen press the home button to close the current program.

3. Low Memory termination

Unlike the general crash structure, which usually consists of free pages,wired pages,purgeable pages,largest process, the colleague lists information about all the processes that the system is running at the current moment.

About memory warning you can see an article I wrote earlier iOS memory warning warning level.

When the app is running, the system will usually warn you when the memory is tight, terminate the program that hangs in the background, and end the process of the current foreground if the memory is not enough.

When the memory warning is received, we should release as much memory as possible, and crash can actually be seen as a protection against the app.

4, Crash due to bugs

Because the program bug caused by crash usually strange, difficult to generalize. Most of the situation through the crash log can locate the problem, of course, do not rule out some of the incurable diseases look half a day is not worth the trouble. This is only to see the foundation, a little bit, always find clues. You can also turn to Google when you do not see the big God, there are people who have the same bug as you

Iii. Common Exception Type & Exception Code

1. Exception Type

1) exc_bad_access

This type of excpetion is our longest-running crash and is typically used to access memory that is not changed. The "()" Behind the general Exc_bad_access will also have additional information.

SIGSEGV: This type should be rarely seen after switching arc, usually due to repeated release of the object.

SIGABRT: The abort signal is received, usually the container in the Foundation library does some testing in order to protect the state, such as inserting nil into the array medium, and encountering such errors.

SEGV: (segmentation violation), representing invalid memory address, such as null pointer, uninitialized pointer, stack overflow, etc.;

Sigbus: Bus error, unlike SIGSEGV, SIGSEGV accesses an invalid address, while Sigbus accesses a valid address, but bus access exceptions (such as address alignment issues)

Sigill: Attempt to execute an illegal instruction that may not be recognized or has no permissions

2)EXC_BAD_INSTRUCTION

This type of exception is usually caused by a thread executing an illegal instruction

3)EXC_ARITHMETIC

This exception is thrown in addition to the 0 error

2. Exception Code

0xbaaaaaad	This type of log means that the crash log is not a real crash, it simply contains the running state of the entire system at some point in time. Can usually be triggered by the user accidentally by pressing the home key and the volume key at the same time
0xbad22222	When a VoIP program is activated too frequently in the background, the system may terminate such programs
0x8badf00d	This has been described earlier, program startup or recovery time too long by watch dog termination
0xc00010ff	The program executes a lot of CPU-and GPU-intensive operations, causing the device to overheat, triggering system overheating protection is terminated by the system
0xdead10cc	System resources are also used when the program is retired to the background, such as contacts being terminated by the system
0xdeadfa11	As mentioned earlier, the program does not respond to user forced shutdown

Iii. ways to obtain crash

1, the Machine

By connecting the test machine through Xcode, all crash logs that occur on the machine can be read directly from the device.

2. itunes Connect

Get the crash log reported to the user via itunes Connect background.

3, third-party crash collection system

There are many excellent third-party crash collection systems that greatly facilitate our collection of crash, even with the ability to symbolize crash logs. More commonly used are crashlytics,flurry and so on.

Iii.Xcode tool symbolicatecrash parsing iOS crash files

First, locate the. app file and the. app.dsym file

• Create a crash folder on the desktop, and then Xcode->window->organizer find archives Find app-> right click on show in
  Finder

• Copy. Apps and. App.dsym to crash folder files: Right-click the. xcarchive file, show package Contents
  Found in the Dsyms folder. App.dsym
  Locate the *.app in the Products->applications folder

Second, find Symbolicatecrash

• 1 find/applications/xcode.app-name symbolicatecrash-type f

• Wait a moment, there will be path output, this path is the path of Symbolicatecrash

• 1/applications/xcode. app/contents/sharedframeworks/dvtfoundation. framework/versions/a/resources/ Symbolicatecrash

• Copy the Symbolicatecrash to the crash folder on the desktop with the command and put it together with the. App and. App.dsym (Manually find Symbolicatecrash, copy it Out)

• 1 cp/applications/xcode. App/contents/sharedframeworks/dvtfoundation. framework/versions/a/resources/ symbolicatecrash/users/the name of your computer/desktop/crash

Iii. implementation of the Symbolicatecrash

• Open the terminal with the command switch to the desktop crash directory:

• 1 cd/users/your computer name/desktop/crash

• Execute command

• 1./symbolicatecrash/users/angelseahappiness/desktop/crash/control_2014-01-13-111838_Lynns-iPad3 . Crash/users/angel/desktop/crash/control. App. DSYM > Control_symbol. Crash

• At this point the terminal may appear:

• 1 Error: "Developer_dir" is not defined on ./symbolicatecrash line .

• Enter the command:

• 1 export developer_dir="/applications/xcode.app/contents/developer"

• And then the terminal will be processed.
• After the terminal is finished, there will be more files in the crash folder Control_symbol.crash: This is the final file, you can see where the bug is located.

Because the crash log above does not understand that the view is hexadecimal address do not know where the problem

The analysis needs to be used when uploading the app. DSYM file. Remember that each time you send a new version to keep the two files, or there is no way to parse crash log, you can first copy the two files to a folder on the desktop, and then the. crash files are also copied under the same folder.

This parsing process needs to be done using Symbolicatecrash, first to find the Symbolicatecrash file

The Symbolicatecrash file is independent of Xcode and can be copied to the folder where you just put crash log, and you need to verify before you start parsing:

1. To view the UUID method for the Xx.app file, enter it at the command line:

$ 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. View the UUID of the. Crash, located in the first row of binary Images: in the crash log. such as: armv7s <13760bde0d073f1eb4d596c3df753f4b>
Only three of them have the same UUID to parse the. crash file and enter it at the command line:

 $./symbolicatecrash xxx.crash Xxx.app.dSYM > Test.log 
 This allows you to convert the. Crash log into a test.log,test.log-readable function file. 
 entering the above command may appear 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, 
 and then continue. Symbolicatecrash xxx.crash xxx.app.dsym > test.log can succeed 
 
 

{"App_name": "Mhdoctor", "timestamp": "2018-05-22 11:08:48.28-0700", "app_version": "1.3.0", "Slice_uuid": " D19af238-ed08-32c2-9882-d9d17f4a3add "," adam_id ": 1110258767," build_version ":" 1.9 "," Bundleid ":" Com.md.MHdoctor ", "Share_with_app_devs": false, "Is_first_party": false, "Bug_type": "109", "os_version": "IPhone os 11.3.1 (15E302)", " incident_id ":" 12cc75f6-9064-4a47-9d7e-e9b6b4d0d69e "," name ":" Mhdoctor "}
Incident Identifier: 12cc75f6-9064-4a47-9d7e-e9b6b4d0d69e
Crashreporter Key:467949c45077b22197dba2880a7275a842d5dbf8
Hardware MODEL:XXX1
Process:mhdoctor [4393]
Path:/private/var/containers/bundle/application/ B3af5423-5751-4eff-b9e6-44f5fa6cfeba/mhdoctor.app/mhdoctor
Identifier:com.md.MHdoctor
version:1.9 (1.3.0)
Code type:arm-64 (Native)
Role:foreground
Parent process:launchd [1]
Coalition:com.md.MHdoctor [2305]< /p>

Date/time:2018-05-22 11:08:48.1360-0700
Launch time:2018-05-22 11:07:56.9302-0700
OS version:iphone os 11.3.1 (15E302)
Baseband version:n/a
Report version:104

Exception Type:exc_crash (SIGABRT)
Exception codes:0x0000000000000000, 0x0000000000000000
Exception note:exc_corpse_notify
Triggered by thread:0

Application Specific information:
Abort () called

Filtered syslog:
None found

Last Exception BackTrace:
0 corefoundation 0x18108ad8c 0x180f45000 + 1334668
1 LIBOBJC. A.dylib 0x1802445ec 0x18023c000 + 34284
2 corefoundation 0x18108abf8 0x180f45000 + 1334264
3 Foundation 0x181a7afa0 0x1819bd000 + 778144
4 UIKit 0x18ac806e0 0x18ac14000 + 444128
5 mhdoctor 0x102f9451c Userdataviewcontroller.imageviewtouch () + 3589404 (userdataviewcontroller.swift:466)
6 mhdoctor 0x102f95410 @objc userdataviewcontroller.viewdidload+ 3593232 () + 27
7 UIKit 0x18ae3a750 0x18ac14000 + 2254672
8 UIKit 0x18b3a72a4 0x18ac14000 + 7942820
9 UIKit 0x18af9ce6c 0x18ac14000 + 3706476
Ten UIKit 0x18ae397a8 0x18ac14000 + 2250664
UIKit 0X18B398AC4 0x18ac14000 + 7883460
UIKit 0x18ae33540 0x18ac14000 + 2225472
UIKit 0x18ae33078 0x18ac14000 + 2224248
UIKit 0X18AE328DC 0x18ac14000 + 2222300
UIKit 0x18ae31238 0x18ac14000 + 2216504
UIKit 0x18b612c0c 0x18ac14000 + 10480652
UIKit 0x18b6151b8 0x18ac14000 + 10490296
UIKit 0x18b60e258 0x18ac14000 + 10461784

At this point, some of the lines before the beginning of the project name change to the address of the call + line number.

Parsing iOS Crash Log (parsing content based on address)

In addition, it is possible to parse the contents of an address in the case of the above three UUID

$ xcrun atos-o xxx.app/xxx-arch armv7 0x38ad42f9 0x38ad42f9 0x38ad42f9 (multiple 16-input addresses, separated by spaces)---method one $ dwarfdump-–lookup 0x0000 36D2-–arch armv6 Xxx.app.dSYM---method two

If you follow the above method, you are prompted to find the address, you can use must kill:

For example, find the address that corresponds to the following:
(The current line of code address = Current address + address offset, the address offset is a decimal value, the formula is written like this, but do not know the exact meaning of the expression, if the same crash, the same position after the same address offset, the previous two values may be changed)

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-l 0x3d000 0x0004fc5c//output: baidudemacbook-pro:1 baidu$ xcrun atos-o/Use Rs/baidu/desktop/1/testtransform.app/testtransform-l 0x3d000 0x0004fc5cgot symbolicator for/users/baidu/desktop/1/ Testtransform.app/testtransform, Base Address 4000main (in Testtransform) (main.m:16)

2. The second relatively complex point, involving the offset of the address, use first to view the start address, even if each iOS app boot will load (main module) The main module in a 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  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 mhdoctor.app.dsym//output Result:--------------------------------------------- -------------------------file:testtransform.app.dsym/contents/resources/dwarf/

Mhdocto

(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 0x000 0B4B9) 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/MHDOCTOR/MHDOCTOR/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 ["] * At_name (" __29-[viewcontroller aaaaaaaaaa:]_block_invoke ") AT_decl_file (" /USERS/BAIDU/DESKTOP/MHDOCTOR/MHDOCTOR/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:ta G_lexical_block [+] * at_LOW_PC (0X0000C0D6) at_high_pc (0x0000c17e) Line table dir: '/users/baidu/desktop/mhdoctor/mhdoctor ' Line table file: ' VIEWCONTROLLER.M ' line 193, column 0 and start address 0x000000000000c11e looking up address:0x000000000000c132 in. Debu G_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/

Mhdocto

. app/

Mhdocto

0xc132//Output Result: __29-[viewcontroller Aaaaaaaaaa:]_block_invoke (in

Mhdocto

) (viewcontroller.m:193)

IOS Crash Log Analysis