常见的信号
- sigsegv：segmentation violation 段错误， 值 11，常见场景，空指针、野指针、栈溢出，终止进程，生成core dump
- sigbus：bus error ，总线错误，值7，地址理论上能访问，但底层硬件/介质让访问失败，不常见，终止进程+core
- sigfpe：float point exception 算数错误，值8，常见场景 整除除零，终止+core
- sigabort：abort 主动放弃， 值6，进程自己触发，常见场景 assert ，c++ 未捕捉异常， 终止+core
- sigill：illegal instruction 非法指令，值4， 常见场景 跳到了非代码区，指令集不匹配， 终止+core
- sigsys：bad system call，值31，几乎只在seccomp 沙箱触发，常见于安全相关的crash，终止+core
- sigchild：child status change，值 17， 子进程状态变化，
dropbox：framework的事件丢箱
tombstone：native crash
记录native 进程崩溃的现场信息，例如进程号、线程号、崩溃地址，调用栈，像墓碑
c++ 程序crash 处理流程
信号产生阶段
Linux 内核通过异常机制，向进程发送对应信号
进程内信号处理
1. 信号处理器安装
进程启动时，Bionic的linker会调用debuggerd_init()， 通过sigaction()注册debuggerd_signal_handler处理
2. 信号触发后
debuggerd_signal_handler 在崩溃线程上下文中执行
- 保存寄存器快找、线程信息到debugger_thread_info
- 通过clone() 创建一个vfork 子进程
- 子进程通过socket连接到 /dev/socker/tombstone_crash，向tombstoned注册自己
3. crash_dump进程接管
tombstoned 派发
- 分配tombstone 文件描述符（/data/tombstones/tombstone_xx）
- 拉起 crash_dump32 / crash_dump64
crash_dump （独立进程）
- ptrace attach 崩溃进程所有线程
- 读取崩溃线程的寄存器、siginfo、/proc/pid/maps
- 使用 libunwindstack 进行栈回溯，解析符号
- dump 内存附近内容，打开的fd、abort message、java stack
- 生成两份输出（tombstone 和logcat输出）
4. init 进程回收与重启
- kernel 跟父进程发送 sigchild
- 父进程是init，根据.rc 配置文件按需重启进程
5. zygote 子进程的特殊处理
如果crash的是app进程
- 进程本身走debuggerd流程，但不会被init重启
- system_server 通过AMS监测进程死亡
java crash 处理流程
1. 异常产生与传播
- ART 抛出异常，通过Thread::ThrowNexException() 创建 java.lang.Throwable 对象，保存到Thread::tlsPtf_.exception
- 栈展开检查是否有try-catch
- 没有捕获的异常，进入 HandleUncaughtExceptions()
2. HandleUncaughtExceptions
默认处理器查找顺序 Thread.dispatchUncaughtException() 依次尝试
ThreadGroup.uncaughtException()
- Thread.getDefaultUncaughtExceptionHandler()
- KillApplicationHandler(App 进程）
- 默认打印到System.err
App进程的关键安装点
RuntimeInit.commonInit() 在zygote fork出app进程时安装 Thread.setDefaultUncaughtExceptionHandler( new KillApplicaitionHandler(loggingHandler))，包含两层处理器
- LoggingHandler 先日志输出
- 真正杀进程
3. KillApplicaitionHandler 处理流程
- 写入logcat
- 通知AMS 通过Binder 调用 acitvityMananger.getService().handleApplicationCrash()
* 传递进程信息 + ApplicationErrorReport.CrashInfo
* AMS接收后进入崩溃处理主流程
- 杀死自己
* Process.killProcess(Process.myPid())
* System.exit(10)
4. AMS端处理
- 收集和落盘
* 调用addErrorToDropBox 写入（/data/system/dropbox/，tag=xxx）
* 增加进程崩溃计数
- 崩溃频率处理
* 短时间内同一个进程多次崩溃，标记为bad process，一定时间内禁止启动
* 系统关键进程连续崩溃可能触发system_server重启或者fallback to safe mode
- 显示ANR/crash 对话框
- 清理进程
▎ 混合情况：Java 进程也可能发生 native crash（JNI 代码崩溃），此时走 native 流程产生 tombstone；如果 native 崩溃发生在 ART 内部，AMS 通过 Process.PROC_DEATH 监听到进程死亡，再补一个 handleApplicationCrash 入口（异常信息从 tombstone 关联）。
ANR 捕捉流程
以input ANR 为例
1. 超时检测机制
* 事件分发给window时，记录 dispatchEntry->deliveryTime
* 每次dispatchOnce的检查队首事件是否超5秒
* 超时调用onAnrLocked，通过InputManagerService.notifyAnr回到java层
* 转给AnrHelper，AMS.inputDispatchingTimeOut
2. AMS 端Anr 处理主流程
* 防重入和黑名单
* 收集pid列表（核心受害者和关联进程），要dump trace 的进程 （崩溃进程本身、system_server、persistent processes、前台进程、有ipc关联的进程）
* 触发anr trace dump
调用dumpStackTraces，向pid发送sigquit信号
+ java 进程收到sigQuit信号处理流程
- art 在启动的时候通过signalCatcher注入了sigquit的处理逻辑
- 收到sigQuit信号时，遍历所有线程，dump（java栈、native 栈、锁持有信息、线程状态、wait、sleep、blocked原因）
- 输出到 /data/anr/trace_xxx
+ native 进程收到sigQuit处理
- 走debuggerd流程，但不是崩溃dump，而是tombstone_intercept的anr/java_trace模式
- dump 全线程 native backtrace
3. 写入dropBox与日志
* addErrorToDropBox tag（data_app_anr、system_app_anr、system_server_anr） 和内容（进程信息、anr内容、CPU使用率快照、trace文件、关联进程trace）
* logcat输出
4. 收集cpu、内存、binder状态
- 用户可见处理
* 前台应用弹框
* 后台应用静默kill
5. 进程清理
如果用户选择关闭或者静默kill
* ProcessRecord.kill Process.killProcessQuiet(pid)，发送sigkill
* zygote回收子进程 （sigchild 到 waitpid）
* AMS cleanupApplicationRecord
* 通知linkToDepth 监听者
* 进程进入badProcess
