IOS Crash 分析 （二）

IOS crash 简述

IOS 开发中遇到Crash是很正常的事情，相信每个开发者都遇到过，有些能复现的crash 很好解决，对于OC项目很多都是野指针问题导致，对于Swifit项目很多都是强解包导致。在上一篇文章中已经收集了很多导致crash的问题汇总。具体请参考：IOS Crash问题分析汇总

线下Crash,我们直接可以调试，结合stack信息，不难定位！，我主要讲解一下线上的Crash情况分析。

线上Crash情况跟踪，我们可以借助很多工作来帮助分析。

• 可以自己集成的第三方源代码如：
  KSCrash源码下载， PLCrashReporter源码下载，CrashKit 源码下载
• 使用第三方框架：
  腾讯Bugly , 友盟，听云，Hockeyapp，Crashlytics

此外，通过iPhone的Crash log也可以分析一些，但是这个是需要用户配合的,因为需要用户在手机 中 设置-> 诊断与用量->勾选 自动发送 ,然后在xcode中 Window->Organizer->Crashes 对应的app,就是当前app最新一版本的crash log ,并且是解析过的,可以根据crash 栈 等相关信息 ,尤其是程序代码级别的 有超链接,一键可以直接跳转到程序崩溃的相关代码,这样更容易定位bug出处.

为了能更快的分析Crash原因，解决Crash问题，需要深入分析；因此，我们需要理解Crash的底层原理。

Crash底层原理

iOS系统自带的 Apple’s Crash Reporter记录在设备中的Crash日志，Exception Type项通常会包含两个元素：Mach异常和 Unix信号。

Exception Type:         EXC_BAD_ACCESS (SIGSEGV)    
Exception Subtype:      KERN_INVALID_ADDRESS at 0x041a6f3

• Mach异常是什么？它又是如何与Unix信号建立联系的？

Mach是一个XNU的微内核核心，Mach异常是指最底层的内核级异常，被定义在下 。每个thread，task，host都有一个异常端口数组，Mach的部分API暴露给了用户态，用户态的开发者可以直接通过Mach API设置thread，task，host的异常端口，来捕获Mach异常，抓取Crash事件。

所有Mach异常都在host层被ux_exception转换为相应的Unix信号，并通过threadsignal将信号投递到出错的线程。iOS中的 POSIX API就是通过Mach之上的 BSD层实现的。

因此，EXC_BAD_ACCESS (SIGSEGV)表示的意思是：Mach层的EXC_BAD_ACCESS异常，在host层被转换成SIGSEGV信号投递到出错的线程。

常见的Crash 原因

1. KVO问题
2. NSNotification线程问题
3. 数组越界
4. 野指针
5. 后台任务超时
6. 内存爆出
7. 主线程卡顿超阀值
8. 死锁

1. 下面我就拿出最常见的两种Crash分析一下

1. crash跟踪
   

2. signal

3. Crash分析处理
   上面我们也知道：既然最终以信号的方式投递到出错的线程，那么就可以通过注册相应函数来捕获信号.到达Hook的效果

+ (void)installUncaughtSignalExceptionHandler{
    NSSetUncaughtExceptionHandler(&LGExceptionHandlers);
    signal(SIGABRT, LGSignalHandler);
}

我们从上面的函数可以Hook到信息，下面我们开始进行包装处理.这里还是面向统一封装，因为等会我们还需要考虑Signal

void LGExceptionHandlers(NSException *exception) {
    NSLog(@"%s",__func__);
    
    NSArray *callStack = [LGUncaughtExceptionHandle lg_backtrace];
    NSMutableDictionary *mDict = [NSMutableDictionary dictionaryWithDictionary:exception.userInfo];
    [mDict setObject:callStack forKey:LGUncaughtExceptionHandlerAddressesKey];
    [mDict setObject:exception.callStackSymbols forKey:LGUncaughtExceptionHandlerCallStackSymbolsKey];
    [mDict setObject:@"LGException" forKey:LGUncaughtExceptionHandlerFileKey];
    
    // exception - myException

    [[[LGUncaughtExceptionHandle alloc] init] performSelectorOnMainThread:@selector(lg_handleException:) withObject:[NSException exceptionWithName:[exception name] reason:[exception reason] userInfo:mDict] waitUntilDone:YES];
}

下面针对封装好的myException进行处理,在这里要做两件事

存储，上传：方便开发人员检查修复
处理Crash奔溃，我们也不能眼睁睁看着BUG闪退在用户的手机上面，希望“起死回生，回光返照”

- (void)lg_handleException:(NSException *)exception{
    // crash 处理
    // 存
    NSDictionary *userInfo = [exception userInfo];
    [self saveCrash:exception file:[userInfo objectForKey:LGUncaughtExceptionHandlerFileKey]];
}

下面是一些封装的一些辅助函数

保存奔溃信息或者上传：针对封装数据本地存储，和相应上传服务器！

- (void)saveCrash:(NSException *)exception file:(NSString *)file{
    
    NSArray *stackArray = [[exception userInfo] objectForKey:LGUncaughtExceptionHandlerCallStackSymbolsKey];// 异常的堆栈信息
    NSString *reason = [exception reason];// 出现异常的原因
    NSString *name = [exception name];// 异常名称
    
    // 或者直接用代码，输入这个崩溃信息，以便在console中进一步分析错误原因
    // NSLog(@"crash: %@", exception);
    
    NSString * _libPath  = [[NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES) objectAtIndex:0] stringByAppendingPathComponent:file];

    if (![[NSFileManager defaultManager] fileExistsAtPath:_libPath]){
        [[NSFileManager defaultManager] createDirectoryAtPath:_libPath withIntermediateDirectories:YES attributes:nil error:nil];
    }
    
    NSDate *dat = [NSDate dateWithTimeIntervalSinceNow:0];
    NSTimeInterval a=[dat timeIntervalSince1970];
    NSString *timeString = [NSString stringWithFormat:@"%f", a];
    
    NSString * savePath = [_libPath stringByAppendingFormat:@"/error%@.log",timeString];
    
    NSString *exceptionInfo = [NSString stringWithFormat:@"Exception reason：%@\nException name：%@\nException stack：%@",name, reason, stackArray];
    
    BOOL sucess = [exceptionInfo writeToFile:savePath atomically:YES encoding:NSUTF8StringEncoding error:nil];
    
    NSLog(@"保存崩溃日志 sucess:%d,%@",sucess,savePath);
}

获取函数堆栈信息，这里可以获取响应调用堆栈的符号信息，通过数组回传

+ (NSArray *)lg_backtrace{
    
    void* callstack[128];
    int frames = backtrace(callstack, 128);//用于获取当前线程的函数调用堆栈，返回实际获取的指针个数
    char **strs = backtrace_symbols(callstack, frames);//从backtrace函数获取的信息转化为一个字符串数组
    int i;
    NSMutableArray *backtrace = [NSMutableArray arrayWithCapacity:frames];
    for (i = LGUncaughtExceptionHandlerSkipAddressCount;
         i < LGUncaughtExceptionHandlerSkipAddressCount+LGUncaughtExceptionHandlerReportAddressCount;
         i++)
    {
        [backtrace addObject:[NSString stringWithUTF8String:strs[i]]];
    }
    free(strs);
    return backtrace;
}

获取应用信息，这个函数提供给Siganl数据封装

NSString *getAppInfo(){
    NSString *appInfo = [NSString stringWithFormat:@"App : %@ %@(%@)\nDevice : %@\nOS Version : %@ %@\n",
                         [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleDisplayName"],
                         [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleShortVersionString"],
                         [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleVersion"],
                         [UIDevice currentDevice].model,
                         [UIDevice currentDevice].systemName,
                         [UIDevice currentDevice].systemVersion];
    //                         [UIDevice currentDevice].uniqueIdentifier];
    NSLog(@"Crash!!!! %@", appInfo);
    return appInfo;
}

做完这些准备，你可以非常清晰的看到程序奔溃，哈哈哈！（好像以前奔溃还不清晰似的），这里说一下：我的意思你非常清晰的知道奔溃之前做了一些什么!
下面是检测我们奔溃之前的沙盒存储的信息：error.log

下面我们来一个骚操作：在监听的信息的时候来了一个Runloop,我们监听所有的mode,开启循环（一个相对于我们应用程序自启的Runloop的平行空间）.

SCLAlertView *alert = [[SCLAlertView alloc] initWithNewWindowWidth:300.0f];
[alert addButton:@"奔溃" actionBlock:^{
    self.dismissed = YES;
}];
[alert showSuccess:exception.name subTitle:exception.reason closeButtonTitle:nil duration:0];
// 本次异常处理
CFRunLoopRef runloop = CFRunLoopGetCurrent();
CFArrayRef   allMode = CFRunLoopCopyAllModes(runloop);
while (!self.dismissed) {
    // machO
    // 后台更新 - log
    // kill
    // 
    for (NSString *mode in (__bridge NSArray *)allMode) {
        CFRunLoopRunInMode((CFStringRef)mode, 0.0001, false);
    }
}

CFRelease(allMode);

在这个平行空间我们开启一个弹框，这个弹框，跟着我们的应用程序保活，并且具备相应的响应能力，到目前为止：此时此刻还有谁！这不就是回光返照？只要我们的条件成立，那么在相应的这个平行空间继续做一些我们的工作，程序不死:what is dead may never die,but rises again harder and stronger

4. signal 函数拦截不到的解决方式
   在debug模式下，如果你触发了崩溃，那么应用会直接崩溃到主函数，断点都没用，此时没有任何log信息显示出来，如果你想看log信息的话，你需要在lldb中，拿SIGABRT来说吧，敲入pro hand -p true -s false SIGABRT命令，不然你啥也看不到。

然后断开断点，程序进入监听，下面剩下的操作就是包装异常，操作类似Exception

最后我们需要注意的针对我们的监听回收相应内存：

 NSSetUncaughtExceptionHandler(NULL);
    signal(SIGABRT, SIG_DFL);
    signal(SIGILL, SIG_DFL);
    signal(SIGSEGV, SIG_DFL);
    signal(SIGFPE, SIG_DFL);
    signal(SIGBUS, SIG_DFL);
    signal(SIGPIPE, SIG_DFL);

    if ([[exception name] isEqual:UncaughtExceptionHandlerSignalExceptionName])
    {
        kill(getpid(), [[[exception userInfo] objectForKey:UncaughtExceptionHandlerSignalKey] intValue]);
    }
    else
    {
        [exception raise];
    }

到目前为止，我们响应的Crash处理已经入门，如果你还想继续探索也是有很多地方比如：

• 我们能否hook系统奔溃，异常的方法NSSetUncaughtExceptionHandler,已达到拒绝传递 UncaughtExceptionHandler的效果

• 我们在处理异常的时候，利用Runloop回光返照，有没有更加合适的方法

• Runloop回光返照我们怎么继续保证应用程序稳定执行

Crash分析中的Signal

1. SIGHUP
   本信号在用户终端连接(正常或非正常)结束时发出, 通常是在终端的控制进程结束时, 通知同一session内的各个作业, 这时它们与控制终端不再关联。
   登录Linux时，系统会分配给登录用户一个终端(Session)。在这个终端运行的所有程序，包括前台进程组和后台进程组，一般都属于这个 Session。当用户退出Linux登录时，前台进程组和后台有对终端输出的进程将会收到SIGHUP信号。这个信号的默认操作为终止进程，因此前台进 程组和后台有终端输出的进程就会中止。不过可以捕获这个信号，比如wget能捕获SIGHUP信号，并忽略它，这样就算退出了Linux登录， wget也 能继续下载。
   此外，对于与终端脱离关系的守护进程，这个信号用于通知它重新读取配置文件。

2. SIGINT
   程序终止(interrupt)信号, 在用户键入INTR字符(通常是Ctrl-C)时发出，用于通知前台进程组终止进程。

3. SIGQUIT
   和SIGINT类似, 但由QUIT字符(通常是Ctrl-)来控制. 进程在因收到SIGQUIT退出时会产生core文件, 在这个意义上类似于一个程序错误信号。

4. SIGILL
   执行了非法指令. 通常是因为可执行文件本身出现错误, 或者试图执行数据段. 堆栈溢出时也有可能产生这个信号。

5. SIGTRAP
   由断点指令或其它trap指令产生. 由debugger使用。

6. SIGABRT
   调用abort函数生成的信号。

7. SIGBUS
   非法地址, 包括内存地址对齐(alignment)出错。比如访问一个四个字长的整数, 但其地址不是4的倍数。它与SIGSEGV的区别在于后者是由于对合法存储地址的非法访问触发的(如访问不属于自己存储空间或只读存储空间)。

8. SIGFPE
   在发生致命的算术运算错误时发出. 不仅包括浮点运算错误, 还包括溢出及除数为0等其它所有的算术的错误。

9. SIGKILL
   用来立即结束程序的运行. 本信号不能被阻塞、处理和忽略。如果管理员发现某个进程终止不了，可尝试发送这个信号。

10. SIGUSR1
    留给用户使用

11. SIGSEGV
    试图访问未分配给自己的内存, 或试图往没有写权限的内存地址写数据.

12. SIGUSR2
    留给用户使用

13. SIGPIPE
    管道破裂。这个信号通常在进程间通信产生，比如采用FIFO(管道)通信的两个进程，读管道没打开或者意外终止就往管道写，写进程会收到SIGPIPE信号。此外用Socket通信的两个进程，写进程在写Socket的时候，读进程已经终止。

14. SIGALRM
    时钟定时信号, 计算的是实际的时间或时钟时间. alarm函数使用该信号.

15. SIGTERM
    程序结束(terminate)信号, 与SIGKILL不同的是该信号可以被阻塞和处理。通常用来要求程序自己正常退出，shell命令kill缺省产生这个信号。如果进程终止不了，我们才会尝试SIGKILL。

16. SIGCHLD
    子进程结束时, 父进程会收到这个信号。
    如果父进程没有处理这个信号，也没有等待(wait)子进程，子进程虽然终止，但是还会在内核进程表中占有表项，这时的子进程称为僵尸进程。这种情 况我们应该避免(父进程或者忽略SIGCHILD信号，或者捕捉它，或者wait它派生的子进程，或者父进程先终止，这时子进程的终止自动由init进程 来接管)。

17. SIGCONT
    让一个停止(stopped)的进程继续执行. 本信号不能被阻塞. 可以用一个handler来让程序在由stopped状态变为继续执行时完成特定的工作. 例如, 重新显示提示符
    SIGSTOP
    停止(stopped)进程的执行. 注意它和terminate以及interrupt的区别:该进程还未结束, 只是暂停执行. 本信号不能被阻塞, 处理或忽略.

18. SIGTSTP
    停止进程的运行, 但该信号可以被处理和忽略. 用户键入SUSP字符时(通常是Ctrl-Z)发出这个信号

19. SIGTTIN
    当后台作业要从用户终端读数据时, 该作业中的所有进程会收到SIGTTIN信号. 缺省时这些进程会停止执行.

20. SIGTTOU
    类似于SIGTTIN, 但在写终端(或修改终端模式)时收到.

21. SIGURG
    有”紧急”数据或out-of-band数据到达socket时产生.

22. SIGXCPU
    超过CPU时间资源限制. 这个限制可以由getrlimit/setrlimit来读取/改变。

23. SIGXFSZ
    当进程企图扩大文件以至于超过文件大小资源限制。

24. SIGVTALRM
    虚拟时钟信号. 类似于SIGALRM, 但是计算的是该进程占用的CPU时间.

25. SIGPROF
    类似于SIGALRM/SIGVTALRM, 但包括该进程用的CPU时间以及系统调用的时间.

26. SIGWINCH
    窗口大小改变时发出.

27. SIGIO
    文件描述符准备就绪, 可以开始进行输入/输出操作.

28. SIGPWR
    Power failure

29. SIGSYS
    非法的系统调用。

• 关键点注意

在以上列出的信号中，程序不可捕获、阻塞或忽略的信号有：SIGKILL,SIGSTOP

不能恢复至默认动作的信号有：SIGILL,SIGTRAP

默认会导致进程流产的信号有：SIGABRT,SIGBUS,SIGFPE,SIGILL,SIGIOT,SIGQUIT,SIGSEGV,SIGTRAP,SIGXCPU,SIGXFSZ

默认会导致进程退出的信号有:
SIGALRM,SIGHUP,SIGINT,SIGKILL,SIGPIPE,SIGPOLL,SIGPROF,SIGSYS,SIGTERM,SIGUSR1,SIGUSR2,SIGVTALRM

默认会导致进程停止的信号有：SIGSTOP,SIGTSTP,SIGTTIN,SIGTTOU

默认进程忽略的信号有：SIGCHLD,SIGPWR,SIGURG,SIGWINCH

此外，SIGIO在SVR4是退出，在4.3BSD中是忽略；SIGCONT在进程挂起时是继续，否则是忽略，不能被阻塞。

Crash分析中的常用调式命令