• 注册
  • 前端博客 前端博客 关注:0 内容:1122

    「ANR」Android SIGQUIT(3) 信号拦截与处理

  • 查看作者
  • 打赏作者
  • 当前位置: 职业司 > 前端开发 > 前端博客 > 正文
    • 前端博客
    • 「ANR」Android SIGQUIT(3) 信号拦截与处理

      作者:非台

      背景

      Android的ANR频次(Application Not Responding)一直是Android用户体验的重要指标,然而在Android 6.0+的设备上,由于设备anr目录权限的收敛,已经不能通过扫描/data/anr/traces.txt文件来获取ANR文件了,因此今天我们来简单聊聊获取ANR的另一种方式,Android环境下,信号SIGQUIT(3)拦截。

      信号量处理

      关于信号SIGQUIT的拦截,我们需要了解信号量处理的部分相关函数,kill、signal、sigaction、sigwait、pthread_sigmask等系统信号量处理相关函数是阅读本文的必备知识,因此在这一章节简单介绍下,更多系统函数知识,请阅读《UNIX环境高级编程》。

      kill [1]

      头文件:#include<signal.h>

      定义函数:int kill(pid_t pid,int signo)

      函数说明:kill函数可以对进程发送signal,Android AMS在发生ANR的是其实是通过Process.sendSignal(pid,signal)来通信的,Process.sendSignal方法在JNI层,其实调用的是kill

      想详细了解ANR的同学可以看

      • AppErrors.java: 链接
      • android_util_Process.cpp: 链接

      signal [2]

      头文件:#include<signal.h>

      定义函数:sig_t signal(int signum,sig_t handler);

      函数说明:signal()用于确定以后当信号sig出现时的处理方法。如果handler的值是SIG_DFL,那么就采用实现定义的缺省行为;如果handler的值是SIG_IGN,那么就忽略该信号;否则,调用handler所指向的函数(参数为信号类型)。有效的信号包括:

      SIGABRT 异常终止,如调用abort()。
      SIGFPE 算术运算出错,如除数为0或溢出。
      SIGILL 非法函数映象,如非法指令。
      SIGINT 交互式信号,如中断。
      SIGSEGV 非法访问存储器,如访问不存在的内存单元。
      SIGTERM 发送给本程序的终止请求信号。

      signal()返回信号sig原来的handler;如果出错,则返回SIG_ERR。当随后出现信号sig时,就中断正在执行的操作,转而执行信号处理函数(*handler)(sig)。如果从信号处理程序中返回,则从中断的位置继续执行。

      sigaction [3]

      头文件:#include<signal.h>

      定义函数:int sigaction(int signum,const struct sigaction *act ,struct sigaction *oldact)

      函数说明:sigaction会依参数signum指定的信号编号来设置该信号的处理函数。参数signum可以指定SIGKILL和SIGSTOP以外的所有信号。如参数结构sigaction定义如下:

      struct sigaction {
      void (*sa_handler)(int);
      void (*sa_sigaction)(int, siginfo_t *, void *);
      sigset_t sa_mask;
      int sa_flags;
      void (*sa_restorer)(void);
      };
      

      代码1 sigaction结构体

      信号处理函数可以采用void (*sa_handler)(int)或void (*sa_sigaction)(int, siginfo_t *, void *)。到底采用哪个要看sa_flags中是否设置了SA_SIGINFO位,如果设置了就采用void (*sa_sigaction)(int, siginfo_t *, void *),此时可以向处理函数发送附加信息;默认情况下采用void (*sa_handler)(int),此时只能向处理函数发送信号的数值。

      • sa_handler:此参数和signal()的参数handler相同,代表新的信号处理函数,其他意义请参考signal();

      • sa_mask:用来设置在处理该信号时暂时将sa_mask指定的信号集搁置;

      • sa_restorer:此参数没有使用;

      • sa_flags :用来设置信号处理的其他相关操作,下列的数值可用。sa_flags还可以设置其他标志:

      • SA_RESETHAND:当调用信号处理函数时,将信号的处理函数重置为缺省值SIG_DFL

      • SA_RESTART:如果信号中断了进程的某个系统调用,则系统自动启动该系统调用

      • SA_NODEFER :一般情况下, 当信号处理函数运行时,内核将阻塞该给定信号。但是如果设置SA_NODEFER标记, 那么在该信号处理函数运行时,内核将不会阻塞该信号。

      sigwait [4]

      头文件:#include<signal.h>

      定义函数:int sigwait(const sigset_t *set, int *sig) ;

      函数说明:sigwait提供了一种等待信号的到来,以串行的方式从信号队列中取出信号进行处理的机制。sigwait只等待函数参数中指定的信号集,即如果新产生的信号不在指定的信号集内,则 sigwait继续等待。对于一个稳定可靠的程序,我们一般会有一些疑问:

      1. 不要在线程的信号掩码中阻塞不能被忽略处理的两个信号 SIGSTOP 和 SIGKILL;
      2. 不要在线程的信号掩码中阻塞 SIGFPE、SIGILL、SIGSEGV、SIGBUS;
      3. 确保 sigwait等待的信号集已经被进程中所有的线程阻塞;
      4. 在主线程或其它工作线程产生信号时,必须调用 kill() 将信号发给整个进程,而不能使用 pthread_kill() 发送某个特定的工作线程,否则信号处理线程无法接收到此信号;
      5. 因为 sigwait使用了串行的方式处理信号的到来,为避免信号的处理存在滞后,或是非实时信号被丢失的情况,处理每个信号的代码应尽量简洁、快速,避免调用会产生阻塞的库函数。

      注:Android的“Signal Catcher”线程是通过sigwait来等待SIGQUIT信号。

      pthread_sigmask [5]

      头文件:#include<signal.h>

      定义函数:int pthread_sigmask (int how,const sigset_t *set,sigset_t *oset);

      函数说明:每个线程均有自己的信号屏蔽集(信号掩码),可以使用pthread_sigmask函数来屏蔽某个线程对某些信号的响应处理,仅留下需要处理该信号的线程来处理指定的信号。实现方式是:利用线程信号屏蔽集的继承关系(在主线程中对sigmask进行设置后,主线程创建出来的线程将继承主线程的掩码)。

      signal、sigaction、sigwait 的差异

      signal、sigaction、sigwait这三个方法都可以接收信号,并处理,那么他们的差异有哪些,以及处理顺序如何?

      sigaction 和 signal 的区别:内核里有signal系统调用函数,它注释里也说是为了向后兼容,功能已被sigaction取代了,详见《源码剖析signal和sigaction的区别》[6],也就是可以理解为signal的能力是sigaction的子集,signal和sigaction最终都是调了系统调用rt_sigaction。

      sigaction 和 sigwait 的区别: 如果多个线程在sigwait调用时,等待的是同一个信号,当信号递送的时候,只有一个线程可以从sigwait中返回,具体是那个线程则是未定义的(由系统决定)。如果信号被捕获(进程通过使用sigaction建立了一个信号处理程序),而且线程正在sigwait调用中等待同一信号,那么这时将由操作系统实现来决定以何种方式递送信号。在这种情况下,操作系统实现可以让sigwait返回,也可以激活信号处理程序,但不可能出现两者皆可的情况。

      我们做了一个实验,如果信号量发送给目标线程,且目标现在存在sigwait,则执行sigwait;如果信号量发送给目标线程,且目标线程设置SIG_BLOCK(屏蔽信息),其他线程在sigwait,则执行sigwait;其他状态执行sigaction的行为—— 这个只在笔者的MAC电脑上实验的结论。

      使用sigwait的好处在于它可以简化信号处理,允许把异步产生的信号用同步的方式处理。为了防止信号中断线程,可以把信号加到每个线程的信号屏蔽字中,然后安排专用线程作信号处理。这些专用线程可以进行函数调用,不需要担心在信号处理程序中调用哪些函数是安全的,因为这些函数调用来自正常的线程环境,而非传统的信号处理程序,传统信号处理程序通常会中断线程的正常执行。详见《Libev源码分析06》[7]。

      Android系统ANR SIGQUIT(3)的处理

      有了前面的前置知识点,我们来看,Android ANR信号机制是怎么做的呢?简单的说:目标进程在创建的时候,会启动一个“Signal Catcher”专项线程来处理信号量,AMS在弹对话框的同时,会有一个系统调用,发出SIGQUIT(3)信号量,“Signal Catcher”专门来处理SIGQUIT(3)信号量,从而dump目标进程的线程状态到/data/anr/traces.txt文件。

      SignalCatcher 线程创建

      当Android运行应用时,如果应用进程还没有创建,ActivityManagerService会请求Zygote fork进程(详见《Android应用进程的创建过程》[8])最终会通过Runtime 创建“SignalCatcher”线程。

      1550  // Look for a native bridge.
      1551  //
      1552  // The intended flow here is, in the case of a running system:
      1553  //
      1554  // Runtime::Init() (zygote):
      1555  //   LoadNativeBridge -> dlopen from cmd line parameter.
      1556  //  |
      1557  //  V
      1558  // Runtime::Start() (zygote):
      1559  //   No-op wrt native bridge.
      1560  //  |
      1561  //  | start app
      1562  //  V
      1563  // DidForkFromZygote(action)
      1564  //   action = kUnload -> dlclose native bridge.
      1565  //   action = kInitialize -> initialize library
      1566  //
      bool Runtime::Init(RuntimeArgumentMap&& runtime_options_in) {
      1110  // (b/30160149): protect subprocesses from modifications to LD_LIBRARY_PATH, etc.
      1111  // Take a snapshot of the environment at the time the runtime was created, for use by Exec, etc.
      1112  env_snapshot_.TakeSnapshot();
      ......
      // 这行代码非常重要,这里后面会解释为什么SIGQUIT信号量,我们拿不到的原因。
      1359  BlockSignals();
      1360  InitPlatformSignalHandlers();
      1361  ......
      1408  std::string error_msg;
      1409  java_vm_ = JavaVMExt::Create(this, runtime_options, &error_msg);
      1410  if (java_vm_.get() == nullptr) {
      1411    LOG(ERROR) << "Could not initialize JavaVMExt: " << error_msg;
      1412    return false;
      1413  }
      ......
      1623  return true;
      1624}
      

      代码2 Runtime::Init 方法

      1905 void Runtime::BlockSignals() {
      1906  SignalSet signals;
      1907  signals.Add(SIGPIPE);
      1908  // SIGQUIT is used to dump the runtime's state (including stack traces).
      1909  signals.Add(SIGQUIT);
      1910  // SIGUSR1 is used to initiate a GC.
      1911  signals.Add(SIGUSR1);
      //将SIGPIPE、SIGQUIT、SIGUSER1加入目标信号集,底层还是调用了 pthread_sigmask 函数,详见附件
      1912  signals.Block();
      1913}
      

      代码3 Runtime::BlockSignals 方法

      代码2、代码3是Runtime初始化信号量的方法,这里通过pthread_sigmask(SignalSet内部实现,有兴趣的小伙伴可以看signal_set.h)屏蔽了SIGPIPE、SIGQUIT、SIGUSER1信号量,使得当前线程(主线程)不会去处理系统发送的SIGPIPE、SIGQUIT、SIGUSER1信号量、由其他线程去处理。

      由于Zogyte在fork子进程时,子进程会继承父进程的信号集,因此子进程创建的主线程,以及主线程创建的子线程都会继承这信号集,导致fork的子进程的主线程以及其子线程都不会处理SIGPIPE、SIGQUIT、SIGUSER1信号,只能通过sigwait来处理。

      SignalCatcher 原理

      [->signal_catcher.cc]
      void* SignalCatcher::Run(void* arg) {
      ...
      // Set up mask with signals we want to handle.
      // part1 拦截SIGQUIT和SIGUSR1 信号
      // 这里创建了一个SignalSet对象
      SignalSet signals;
      //将SIGQUIT、SIGUSER1加入目标信号集,底层还是调用了 sigaddset 函数,详见附件
      signals.Add(SIGQUIT);
      signals.Add(SIGUSR1);
      while (true) {
      //等待目标信号SIGQUIT、SIGUSR1发生,底层还是调用了 sigwait 函数,详见附件
      int signal_number = signal_catcher->WaitForSignal(self, signals);
      if (signal_catcher->ShouldHalt()) {
      runtime->DetachCurrentThread();
      return nullptr;
      }
      switch (signal_number) {
      // part2 处理 SIGQUIT 信号
      case SIGQUIT:
      signal_catcher->HandleSigQuit();
      break;
      case SIGUSR1:
      signal_catcher->HandleSigUsr1();
      break;
      default:
      LOG(ERROR) << "Unexpected signal %d" << signal_number;
      break;
      }
      }
      }
      

      代码4 SignalCatcher::Run 方法

      代码4 SignalCatcher::Run方法,正如前面所说,Android系统确实通过了“SignalCatcher”线程通过pthread_sigmask和sigwait来专项处理SIGQUIT、SIGUSR1的信号量。Android系统如此设计,我的理解是为了保障SIGQUIT、SIGUSR1的处理一定由“SignalCatcher”线程来完成,我认为这里由两个优点:

      1. 防止信号量被其他线程处理,确保ANR文件内容的正确性;
      2. 由单独线程处理,可以防止对其他线程的堆栈破坏,保障线程堆栈的完整性。

      Android自定义SIG_QUIT拦截的实现

      // 去监听 SIGQUIT 信号量
      void RunSigQuitMonitor() {
      sigset_t set, old_set;
      sigemptyset(&set);
      sigaddset(&set, SIGQUIT);
      /*
      * 这里需要调用SIG_UNBLOCK,因为目标进程被Zogyte fork出来的时候,主线程继承了
      * Zogyte的主线程的信号屏蔽关系,Zogyte主线程在初始化的时候,通过
      * pthread_sigmask SIG_BLOCK把SIGQUIT的信号给屏蔽了,因此我们需要在自己进程的主线程,
      * 设置pthread_sigmask SIG_UNBLOCK ,这会导致原来的SignalCatcher sigwait将失效,
      * 原因是SignalCatcher 线程会对SIGQUIT 信号处理
      */
      int r = pthread_sigmask(SIG_UNBLOCK, &set, &old_set);
      if (0 != r) return;
      ... ...
      struct sigaction sa;
      memset(&sa, 0, sizeof(sa));
      sigemptyset(&sa.sa_mask);
      sigaddset(&sa.sa_mask, SIGQUIT);
      sa.sa_sigaction = SignalHandler;
      sa.sa_flags = SA_ONSTACK | SA_SIGINFO;
      if (sigaction(SIGQUIT, &sa, &old_handler) != 0) {
      goto Failed;
      }
      return;
      Failed:
      //如果失败需要恢复原先的状态,保障原来的工作能继续完成(主要是SignalCatcher)
      pthread_sigmask(SIG_SETMASK, &old_set, NULL);
      }
      

      代码5 SIG_QUIT拦截自定义SigPad::RunSigQuitMonitor方法

      代码5 SigPad::RunSigQuitMonitor 方法,有了Linux信号的前置知识以及对Android “SignalCatcher”初始化的介绍,我们可以通过pthread_sigmask设置SIG_UNBLOCK来解除当前进程主线程对SIGQUIT的屏蔽。再通过sa_sigaction对SIGQUIT信号量处理方法重定向,从而实现自己的ANR监控方法。

      小结

      以上,有了对 Android SIGQUIT 信号处理的了解,我们就可以快速实现 Android 自定义的 SIGQUIT 信号拦截器,也欢迎广大读者朋友留言交流。

      引用

      [1] 链接()/2680256

      [2] 链接

      [3] 链接

      [4] 链接

      [5] 链接

      [6] 源码剖析signal和sigaction的区别: 链接

      [7] Libev源码分析06: 链接

      [8] Android应用进程的创建过程: 链接

      关注我们,每周 3 篇移动技术实践&干货给你思考!

      请登录之后再进行评论

      登录

      手机阅读天地(APP)

      • 微信公众号
      • 微信小程序
      • 安卓APP
      手机浏览,惊喜多多
      匿名树洞,说我想说!
      问答悬赏,VIP可见!
      密码可见,回复可见!
      即时聊天、群聊互动!
      宠物孵化,赠送礼物!
      动态像框,专属头衔!
      挑战/抽奖,金币送不停!
      赶紧体会下,不会让你失望!
    • 实时动态
    • 签到
    • 做任务
    • 发表内容
    • 偏好设置
    • 到底部
    • 帖子间隔 侧栏位置:
    • 还没有账号?点这里立即注册