一 总述

下面是一份dump 的log：

810   876 I system_server: libdebuggerd_client: started dumping process 678
740   740 I /system/bin/tombstoned: registered intercept for pid 678 and type kDebuggerdNativeBacktrace
678   678 I libc    : Requested dump for tid 678 (cameraserver)
740   740 I /system/bin/tombstoned: received crash request for pid 678
740   740 I /system/bin/tombstoned: enqueueing crash request for pid 678
740   740 I /system/bin/tombstoned: found intercept fd 512 for pid 678 and type kDebuggerdNativeBacktrace
7840  7840 I crash_dump32: performing dump of process 678 (target tid = 678)

涉及到的模块有：

1 system_server

2 debuggerd

3 target_pid

4 crash_dump

5 debuggerd_client

6 tombstoned

1和2 system_server 和debuggerd都是调用的5 debuggerd_client 实现的。

二者区别:

system_server 可能是写到文件中的，如anr文件；

debuggerd是打印到标准输出上STDOUT_FILENO

3 target_pid 与4 crash_dump 是同一个code，3 target_pid会在fork出来一个进程（就是4 crash_dump）实现dump  trace的功能

总体实现方法是：

1 各进程间的通信是使用socket实现的。

2 当建立socket 通信后，debuggerd_client会发送signal 给target_pid，target_pid使用signal catcher处理对应的signal信号，就是crash_dump逻辑了。

二  ANR触发dump trace信息

举例system server中的逻辑：抓anr的trace信息

watchdog里面会监控system server主要service的状态，如果发生anr就会监控到，然后调用ActivityManagerService.dumpStackTrace API,。

这个api中会有需要dump的进程信息，其中watchdog中指定dump的native 进程，ams 还会其他check的extra 进程。

然后for循环dump每个进程的trace信息。

ams>android_os_Debug>debuggerd_client.dump_backtrace_to_file_timeout>debuggerd_trigger_dump

这些API都是在system_server 进程中。

debuggerd进程的实现也依赖这个debuggerd_trigger_dump。

debuggerd_trigger_dump 就是在debuggerd_client中实现的了。后面再介绍。

三 tombstoned 进程

开机就会启动的进程，

创建三个socket：

constexpr char kTombstonedCrashSocketName[] = "tombstoned_crash";
constexpr char kTombstonedJavaTraceSocketName[] = "tombstoned_java_trace";
constexpr char kTombstonedInterceptSocketName[] = "tombstoned_intercept";

1 tombstoned与debuggerd_client 的通信是使用socket "tombstoned_intercept"。

debuggerd_client 向tombstoned_intercept发送InterceptRequest 请求，tombstone中的intercept_manager 处理该请求，并返回intercept的状态，如register/started/failed等。

2 tombstoned 与crash_dump的通信使用socket “tombstoned_crash” 或“tombstoned_java_trace”，这个是根据dump的type决定的。

crash_dump建立联系后，向tombstoned发送kDumpRequest 请求，然后tombstoned返回kPerformDump，并同outputfd一块返回。

所以tombstoned逻辑中会有两个逻辑：一个是处理intercept（使用intercept_manager）另一个是处理crash_request.

四 crash_dump64 进程

这个是dump进程的东西，往dump进程中发送signal 信息，这边就会收到signal 信号，然后由signal 处理程序处理。

然后fork一个进程专门处理dump的功能。

在新进程中，

1与tombstoned 建立socket 通信，

2 发送kDumpRequest并等待kPerformDump。

3 dump的逻辑

4 通知dump conplete

五 总体流程

A tombstone 进程启动，创建好三个socket

B 各进程启动，加载signal catcher

C 出现anr情况， system server watchdog 逻辑monitor 问题，触发ams.dumpstacktrace

然后就是上图的流程了

复杂的是tombstoned的消息处理逻辑：

intercept msg使用InterceptManager

crash msg使用内部的crash和crashQueue

intercept_manager.cpp中 intercept_accept_cb/ intercept_request_cb / intercept_close_cb

tombstoned.cpp中 crash_accept_cb/crash_request_cb/ crash_completed_cb/perform_request

intercept_request_cb 处理与debuggerd_client的通信，接收request，发送register和started

crash_request_cb/perform_request 处理与crash_dump的通信，接收kDumpRequest/发送kPerformDump

perform_request 里面会check intercept_manager 中是否有匹配项，并将获取其outputfd。

当crash_dump将所有需要的堆栈信息获取到后，通知tombstone kCompletedDump

tombstone中由crash_completed_cb 接收complete消息，并打印写到什么文件中。

【注意outputfd】

如果是system server获取的anr信息，则outputfd是anr文件，是由debuggerd_client 通过socket传递给intercept_manager 中，保存在数组中。

在接收到dumpRequest命令后，tombstone会check intercept数组，获取到对应的outputfd，传递给crash_dump 进程中，所有的dump实现中都是直接写到这个outputfd中了。

如果是target _pid 自己出现的crash等信息，这个outputfd 就是在tombstoned中自己创建的，

perform_request > null = GetIntercept > CrashQueue::for_crash(crash.get())->get_output(crash->crash_type) >  create_temporary_file 

crash_completed_cb > crash_completed > rename_tombstone_fd > /data/tombstones/tombstone_00