English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
Common iOS Crash Tracking Methods and Bugly Integration
When the app crashes, during the development phase, crash information can generally be tracked in the following ways
#1.Run the simulator and check the Xcode error log
#2.Real device debugging, view the xcode error log
#3.Run the device and check the device system log
Here is an example to illustrate, first write a piece of code that will crash: crashdemo:
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
[self performSelector:@selector(print) withObject:nil afterDelay:5];
}
- (void)print {
NSArray *array = @[];
NSLog(@"%@", array[1]);
}
Demo#1.Run the simulator and check the Xcode error log
The program will crash immediately after execution. Open the Xcode system log to see the following error information
2016-10-29 12:13:29.015 CrashDemo[37842:7436441] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArray0 objectAtIndex:]: index 1 beyond bounds for empty NSArray' *** First throw call stack: ( 0 CoreFoundation 0x00b7ba84 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x00642e02 objc_exception_throw + 50 2 CoreFoundation 0x00b22390 __CFArrayGetTypeID_block_invoke + 0 3 CoreFoundation 0x00ac07f8 -[NSArray objectAtIndexedSubscript:] + 40 4 CrashDemo 0x000877b7 -[ViewController print] + 87 5 Foundation 0x00250d71 __NSFireDelayedPerform + 442 6 CoreFoundation 0x00acd576 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22 7 CoreFoundation 0x00accf72 __CFRunLoopDoTimer + 1250 8 CoreFoundation 0x00a8b25a __CFRunLoopRun + 2202 9 CoreFoundation 0x00a8a706 CFRunLoopRunSpecific + 470 10 CoreFoundation 0x00a8a51b CFRunLoopRunInMode + 123 11 GraphicsServices 0x041e4664 GSEventRunModal + 192 12 GraphicsServices 0x041e44a1 GSEventRun + 104 13 UIKit 0x00f0c1eb UIApplicationMain + 160 14 CrashDemo 0x00087bba main + 138 15 libdyld.dylib 0x03189a21 start + 1 ) libc++abi.dylib: terminating with an uncaught exception of type NSException (lldb)
From the xcode log, we can see that there is an array access out of bounds, and the out of bounds method name is print
For this demo, of course, we are very clear that it is the array[1]is out of bounds, but how can we view where the out of bounds occurs in a complete program?63;
At this time, we can use the 'Show the breakpoint navigator' feature of xcode, click the plus sign to select 'add exception breakpoint'
At this time, when we run the program, xcode will automatically stop at the code segment where the crash will occur
Demo#2.Real device debugging, view the xcode error log
If an exception point is added, the program will automatically stop at the printing of array[1]on that line. If it is not added, the program will crash, and xcode will show the following error log
2016-10-29 12:15:53.561 CrashDemo[1062:316582] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArray0 objectAtIndex:]: index 1 beyond bounds for empty NSArray' *** First throw call stack: (0x211b398b 0x2094ee17 0x211433e7 0xc5a3b 0x219d1ad5 0x211765ff 0x21176231 0x2117407d 0x210c32e9 0x210c30d5 0x226b3ac9 0x257880b9 0xc5c99 0x20d6b873) libc++abi.dylib: terminating with an uncaught exception of type NSException (lldb)
From the error message, we can only see that there is an array access out of bounds, and if an exception breakpoint is added, it will automatically stop at the line where the error occurs.
Demo#3Run on a real device and view the device system log
xcode stops running this crashdemo and selects the xcode window - devices, select the phone - view device logs
Then run crashdemo on the phone, and view the latest log in the device logs sorted by time to see the crash log of crashdemo
Incident Identifier: 9A4C52F0-B0D7-42C9-A7CB-D4D3321D00D5 CrashReporter Key: 90f4d3621773443794fa73f506fd6bdef49fc269 Hardware Model: iPhone4,1 Process: CrashDemo [1074] Path: /private/var/containers/Bundle/Application/1307034E-9C2B-451F-ACD9-04C97DEC047B/CrashDemo.app/CrashDemo Identifier: PEGA.CrashDemo Version: 1 (1.0) Code Type: ARM (Native) Parent Process: launchd [1] Date/Time: 2016-10-29 12:21:49.49 +0800 Launch Time: 2016-10-29 12:21:43.43 +0800 OS Version: iOS 9.3.1 (13E238) Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Triggered by Thread: 0 Filtered syslog: None found Last Exception Backtrace: 0 CoreFoundation 0x211b3986 __exceptionPreprocess + 122 1 libobjc.A.dylib 0x2094ee12 objc_exception_throw + 34 2 CoreFoundation 0x211433e2 -[__NSArray0 objectAtIndex:] + 110 3 CrashDemo 0x000e6a36 0xe0000 + 27190 4 Foundation 0x219d1ad0 __NSFireDelayedPerform + 464 5 CoreFoundation 0x211765fa
These can be easily implemented in the development stage, but what if the app crashes after it is released to users? Generally, users can only feedback when the crash occurs.
Then we try to see if we can encounter it, but this is not very efficient and it is generally difficult to reproduce the user's crash.
Bugly solves this problem
When the program crashes, Bugly SDK will automatically send the error information to the server for developers to view and analyze.
So how to use Bugly?
Firstly, go to https://bugly.qq.com/v2/Register an account and register the app to download the SDK package
Drag Bugly.framework into the project and remember to check copy if needed.
Then add libz.tbd / libstdc++.tbd / Security.framework / add SystemConfiguration.framework to the project
register in delegate.m
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[Bugly startWithAppId:@"Please replace it with your AppId"];
return YES;
}
In this way, when the program crashes, the crash information will be automatically sent to the server, and you can view it by logging into your bugly account.
Thank you for reading, I hope it can help everyone, thank you for your support to this site!