保护你的crash

2,118 阅读9分钟

原文链接

如何去衡量一款应用的质量好坏?为了回答这一问题,APM这一目的性极强的工具向开发顺应而生。最早的APM开发只关注于crashcpu这类的硬性指标。而随着移动开发市场的成熟,越来越多的数据指标也被加入到了APM的采集范畴中,包括感官体验相关的数据和使用习惯等。

然而,无论APM最终如何发展,其最核心的采集指标一定是crash数据。一套完善的crash监控方案可以快速的发现并协助完成问题定位,从而能够及时止损,避免更多的损失。而反过来说,如果crash不能及时被发现,又或者因为采集链中出现异常导致了数据丢失,对于开发者和公司来说,这都会是一个噩梦。

crash采集

细分之下,crash分别存在mach exceptionsignal以及NSException三种类型,每一种类型表示不同分层上的crash,也拥有各自的捕获方式。

  • mach exception

    mach异常由处理器陷阱引发,在异常发生后会被异常处理程序转换成Mach消息,接着依次投递到threadtaskhost端口。如果没有一个端口处理这个异常并返回KERN_SUCCESS,那么应用将被终止。每个端口拥有一个异常端口数组,系统暴露了后缀为_set_exception_ports的多个API让我们注册对应的异常处理到端口中。

    mach异常即便注册了对应的处理,也不会导致影响原有的投递流程。此外,即便不去注册mach异常的处理,最终经过一系列的处理,mach异常会被转换成对应的UNIX信号,一种mach异常对应了一个或者多个信号类型。因此在捕获crash要提防二次采集的可能。

  • NSException

    NSException发生在CoreFoundation以及更高抽象层,在CoreFoundation层操作发生异常时,会通过__cxa_throw函数抛出异常。在通过NSSetUncaughtExceptionHandler注册NSException的捕获函数之后,崩溃发生时会调用这个捕获函数。但如果没有任何函数去捕获这个异常 如果在捕获函数中没有进行操作终止应用,最终异常会通过abort()来抛出一个SIGABRT信号。

    由于NSException的抽象层次足够高,相比较其他的crash类型,NSException是可以被人为的阻止crash的。比如@try-catch机制能够捕获块中发生的异常,避免应用被杀死。但由于try-catch的开销和回报不成正比,往往不会使用这种机制。其二是crash防护,这一手段通过hook掉上层接口来规避crash风险,但是只建议用于线上防护,而且hook未必不会导致其他的问题。

  • signal

    signa会导致crash,这是多数iOS开发者对于信号的印象。传递crash信息其实只是信号的一部分功能,信号是一套基于POSIX标准开发的通信机制,具体可以阅读Signal-wikipedia。在signal.h中声明了32种异常信号,下面列出一部分的信号异常对:

    信号 异常
    SIGILL 执行了非法指令,一般是可执行文件出现了错误
    SIGTRAP 断点指令或者其他trap指令产生
    SIGABRT 调用abort产生
    SIGBUS 非法地址。比如错误的内存类型访问、内存地址对齐等
    SIGSEGV 非法地址。访问未分配内存、写入没有写权限的内存等
    SIGFPE 致命的算术运算。比如数值溢出、NaN数值等

    虽然存在三种crash,但由于mach exception会在BSD层被转换成UNIX信号NSException在未被捕获的情况下会调用abort抛出信号,因此即便是我们只注册了signal的处理,只要注册的signal足够多,理论上也是能捕获到全部的crash

采集冲突

由于crash的捕获机制只会保存最后一个注册的handle,因此如果项目中残留或者存在另外的第三方框架采集crash信息时,经常性的会存在冲突。解决冲突的做法是在注册自己的handle之前保存已注册的处理函数,便于发生崩溃后能将crash信息连续的传递下去。

struct sigaction my_action;
static struct sigaction registered_action;
static NSUncaughtExceptionHandler *previousHandle;
    
void signal_handler(int signal) {
    ......
}

void exception_handler(NSException *exception) {
    ......
}
    
void registerCrashHandle() {
    previousHandle = NSGetUncaughtExceptionHandler();
    NSSetUncaughtExceptionHandler(&exception_handler);
    
    myAction.sa_handler = &signal_handler;
    sigemptyset(&my_action.sa_mask);
    sigaction(SIGABRT, &my_action, &registered_action);
}

一般来说,一个经验丰富的开发者在注册crash回调时都会主动的去保存其他函数,避免因为冲突导致别人的数据丢失。但是即便按照这样的方式来注册你的回调,也不代表我们的处理函数是安全的。最重要的原因在于完成回调的注册之后,我们无法保证后续会不会有其他人继续注册,如果有就会存在被替换掉的风险

解决方案

按照正常方式的做法,能保证先于我们注册的crash回调不会被我们拦截导致失败,但如果在我们后方存在另外的注册,我们需要一个有效的机制来保护我们的采集数据。解决问题的收益是不变的,所以解决方案理当尽可能的低开销和低风险。

如何去判断我们的handle是否安全?这要求我们对已注册的handle进行检测。首先检测时机要选择在哪?由于crash是可能发生在应用启动阶段的,因此crash采集一般也是发生在didLaunch这个时间,下图是我绘制的应用启动到完全启动的几个重要阶段:

applicationActive这个阶段基本上是能保证crash相关的注册都完成的,因此冲突检测可以放到这个阶段进行。

周期性检测

利用已有的周期性机制或者使用定时器来进行handle冲突检测。可以分别使用通知定时器两个机制来完成周期性检测方案

  • 监听应用状态

    监听UIApplicationDidBecomeActiveNotification在应用进入活跃状态时做检测:

      - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
          ......
          [[NSNotificationCenter defaultCenter] addObserver: [SignalHandler sharedHandler] selector: @selector(checkRegisterCrashHandler) name: UIApplicationDidBecomeActiveNotification object: nil];
          ......   
      }
      
      static struct sigaction existActions[32];
      static int fatal_signals[] = {
          SIGILL,
          SIGBUS,
          SIGABRT,
          SIGPIPE,
      };
      
      - (void)checkRegisterCrashHandler {
          struct sigaction oldAction;
          for (int idx = 0; idx < sizeof(fatal_signals) / sizeof(int); idx++) {
              sigaction(fatal_signals[idx], NULL, &oldAction);
              if (oldAction.sa_handler != &signal_handler) {
                  existActions[fatal_signals[idx]] = oldAction;
                  
                  struct sigaction myAction;
                  myAction.sa_handler = &signal_handler;
                  sigemptyset(&myAction.sa_mask);
                  sigaction(SIGABRT, &myAction, NULL);
              }
          }
      }
    
  • 定时器检测

    创建定时器来进行周期性的检测,相比通知的机制,可以控制检测间隔:

      - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
          ......
          NSTimer *timer = [[NSTimer alloc] initWithFireDate: [NSDate date] interval: 30 target: [SignalHandler sharedHandler] selector: @selector(checkRegisterCrashHandler) userInfo: nil repeats: YES];
          [[NSRunLoop currentRunLoop] addTimer: timer forMode: NSRunLoopCommonModes];
          [timer fire];
          ......   
      }
    

hook注册函数

通过hook调用注册handle的对应函数,建立一个回调数组来保存非exception_handle的所有回调,后续处理完我们的采集,再逐个调起。由于捕获函数都是基于C接口的,因此我们需要fishhook来提供相应的hook功能。

struct SignalHandler {
    void (*signal_handler)(int);
    struct SignalHandler *next;
}
struct SignalHandler *previousHandlers[32];

void append(struct SignalHandler *handlers, struct SignalHandler *node) { 
    ......
}

static int (*origin_sigaction)(int, const struct sigaction *__restrict, struct sigaction * __restrict) = NULL;

int custom_sigaction(int signal, const struct sigaction *__restrict new_action, struct sigaction * __restrict old_action) {
    if (new_action.sa_handler != signal_handler) {
        append(previousHandlers[signal], new_action);
        return origin_sigaction(signal, NULL, old_action);
    } else {
        return origin_sigaction(signal, new_action, old_action);
    }
}

风险

在周期性检测的方案下,假设存在handle注册链(依次从左到右):

previous <- exception_handle <- other

在检测时发现当前回调是other,于是重新注册我们的回调,保存other。但是假如other也保存了我们的回调,这样可能会导致崩溃发生的时候,调用顺序变成一个死循环。

hook方案则是因为在调用origin_sigaction时会传入old_action,可能导致另外的注册者保存了我们的exception_handle,并在最后处理的时候出现同样的循环调用问题。对于hook方案来说,解决方法要简单很多,只需要在非我们的注册调用origin_sigaction时不传入old_action就能保证其他注册者无法获取到我们的回调:

int custom_sigaction(int signal, const struct sigaction *__restrict new_action, struct sigaction * __restrict old_action) {
    if (new_action.sa_handler != signal_handler) {
        append(previousHandlers[signal], new_action);
        return origin_sigaction(signal, NULL, NULL);
    } else {
        return origin_sigaction(signal, new_action, old_action);
    }
}

而使用周期性监测,就需要考虑是否放弃other的回调,最终只保证exception_handleprevious和更早之前的注册能够被顺利调起。

另外,hook还存在一个风险是假如第三方同样做了hook掉注册函数的处理,并且做了筛选处理,最终导致的结果是没办法完成任何一个注册。两害相较取其轻,个人的建议是使用周期性检测方案。

最简单的方式

上述的两套方案都存在风险点,而且这些风险点对于应用来说都算是致命的。那么有没有几乎没有风险又能解决问题的办法呢?答案是肯定的,那就是不要用有潜在风险的第三方,或者和第三方开发者商量提供一个无需crash采集的版本。

在应用发生崩溃的时候,此时的崩溃所在线程是极不稳定的,不稳定性包括几点:

  • 内存不稳定

    如果是内存相关错误引发的crash,比如内存过载、野指针等,此时线程的内存是危险状态。如果这时候在handle中再次分配内存,极有可能导致二次crash

  • 死锁

    大多数底层的的核心API会涉及到加锁处理,这一情况在signal错误中出现的较多。而作为上层调用方的我们是不自知的,此时错误的操作可能导致线程陷入死锁状态

理论上当我们拦截了一个signal的时候,此时的应用会陷入内核并停止工作,应用页面卡死,这时候我们可执行时长是无限的。如果处理链过长,耗时过多或者陷入某种循环,会造成一种应用卡死而非崩溃的错觉,而经过我厂大量的统计,应用卡死要比应用崩溃更让人难以接受。此外,过多的处理链会增加回调流程上的风险点。如果链条上的某个点发生了二次崩溃,会导致后续的处理都无法执行。因此,不用第三方或者让第三方去除crash采集,是一种可行且高效的手段。

其他

文中提到过一次现在比较流行的crash防护手段,这里还是想说两句。在开发中,crash防护会造成依赖心理,降低对风险的敏感。而在线上,这种方案可能屏蔽了大量的低级错误,也是让我不能容忍的,当然循环引用的防护属于例外。最后安利一波寒神的XXShield,除了容器类的防crash都值得学习,尤其是正确的method swizzling姿势。

参考

Foundation

iOS异常捕获

libc++ api spec

Linux信号处理机制

浅谈Mach Exceptions

漫谈iOS Crash收集框架

源码剖析signal和sigaction的区别

iOS Crash捕获及堆栈符号化思路剖析

关注我的公众号获取更新信息