Android Debuggerd 简要介绍和源码分析（转载）

转载: http://dylangao.com/2014/05/16/android-debuggerd-%E7%AE%80%E8%A6%81%E4%BB%8B%E7%BB%8D%E5%92%8C%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90/

码字很辛苦，转载请注明来自Dylan‘s Zone的《Android Debuggerd 简要介绍和源码分析》

本文以android4.1为基础，分析debuggerd这个工具的使用方法和源码。

1.Debuggerd 简介

debuggerd是一个daemon进程，在系统启动时随着init进程启动。主要负责将进程运行时的信息dump到文件或者控制台中。

1.1 debuggerd的运行原理

创建一个名为 “Android:debuggerd”的socket，作为server端等待其他client端进程的连接
接收client端进程发送来的tid和action信息
将由tid指定的那个进程的运行信息，按照由action指定的动作dump到文件或者控制台中

可以作为debuggerd的client端的进程主要有几种：

异常的C/C++程序

这种程序由bionic的linker安装异常信号的处理函数，当程序产生异常信号时，进入信号处理函数，与debuggerd建立。

debuggerd程序

debuggerd可以在控制台中以命令debuggerd -b [<tid>]启动，然后与debuggerd daemon建立连接。这样debuggerd可以在不中断进程执行的情况下dump由tid指定的进程的信息。

callstack/dumpstate

控制台中运行命令callstack/dumpstate，并指定必要的参数，命令中会调用dump_backtrace_to_file与debuggerd交互

1.2 debuggerd的使用方法

产生异常信号的C/C++程序与debuggerd建立连接后，debuggerd将进程信息dump到tombstone_XX文件中保存到/data/tombstone/文件夹下。可通过查看tombstone_XX分析异常进程的堆栈信息
在控制台中以命令debuggerd -b [<tid>]启动。如果加上-b参数，则由tid指定的进程的信息将dump到控制台上，否则dump到tombstone文件中
控制台中运行命令callstack/dumpstate，进程信息会写入这两个命令指定的文件中

1.3 tombstone文件的分析方法

使用prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6/bin下的工具

arm-linux-androideabi-addr2line 将类似libxxx.so
0x00012345的调用栈16进制值翻译成文件名和函数名 arm-linux-androideabi-addr2line -e
libxxx.so 0x00012345
arm-linux-androideabi-nm 列出文件的符号信息 arm-linux-androideabi-nm -l -C -n -S libdvm.so > dvm.data
arm-linux-androideabi-objdump 列出文件的详细信息 arm-eabi-objdump -C -d libc.so > libc.s

通过以上工具的分析，可以得到较完整的调用栈以及调用逻辑的汇编码

tombstone文件的分析的实用工具和参考文章：

tombstones.py Python script to retrieve line info from an android
tombstone using ndk-stack and addr2line.
https://github.com/feichh/android-tombstones
android-ndk-stacktrace-analyzer A simple tool for analyzing the
stack trace generated from crashing native code in the android system.
http://code.google.com/p/android-ndk-stacktrace-analyzer/
How to read Android crash log and stack trace This article briefly
explains the structure of the log, how to read it.
http://bootloader.wikidot.com/linux:android:crashlog

1.4 Debuggerd 框架图

2.linker中debugger.c源码分析

bionic libc,是一种 C 标准函式库, 用于 Android 嵌入式系统上。bionic库中的链接器会对以下七种信号设置Handler(debugger_signal_handler)：

SIGILL(非法指令异常)
SIGABRT(abort退出异常)
SIGBUS(硬件访问异常)
SIGFPE(浮点运算异常)
SIGSEGV(内存访问异常)
SIGSTKFLT(协处理器栈异常)
SIGPIPE(管道异常)

链接到bionic库上的C/C++程序崩溃时，内核会发送相应的signal，进程收到异常信号后，会转入debugger_signal_handler函数中进行处理。

debugger_init函数(见文件bionic/linker/debugger.c)中设置信号处理函数

void debugger_init()

{

    struct sigaction act;

    memset(&act, , sizeof(act));

    act.sa_sigaction = debugger_signal_handler;

    act.sa_flags = SA_RESTART | SA_SIGINFO;

    sigemptyset(&act.sa_mask);

    sigaction(SIGILL, &act, NULL);

    sigaction(SIGABRT, &act, NULL);

    sigaction(SIGBUS, &act, NULL);

    sigaction(SIGFPE, &act, NULL);

    sigaction(SIGSEGV, &act, NULL);

    sigaction(SIGSTKFLT, &act, NULL);

    sigaction(SIGPIPE, &act, NULL);

}

debugger_init中act.sa_flags = SA_RESTART | SA_SIGINFO的涵义：

SA_RESTART

如果指定该参数，表示若信号中断了进程的某个系统调用，则系统自动启动该系统调用。如果不指定该参数，则被中断的系统调用返回失败，错误码为 EINTR。这个标志位只要用于处理慢系统调用(可能会被阻塞的系统调用)。比如调用write系统调用写某个设备被阻塞，这时进程捕获某个信号且进入相应信号处理函数返回时，该系统调用可能要返回ENINTR错误。指定这个参数后，系统调用会重启，与RETRY_ON_EINTR宏配合使用则可以保证写操作的完成

SA_SIGINFO

如果指定该参数，表示信号附带的参数(siginfo_t结构体)可以被传递到信号处理函数中。

debugger_signal_handler函数处理流程

debugger_signal_handler函数分析：调用logSignalSummary将signal信息写入文件
调用socket_abstract_client函数与debuggerd建立socket连接
如果连接建立成功，则设置结构体debugger_msg_t，并发送给debuggerd

msg.action = DEBUGGER_ACTION_CRASH;//告诉debuggerd采取何种行

msg.tid = tid;//线程号

RETRY_ON_EINTR(ret, write(s, &msg, sizeof(msg)));

等待debuggerd的回复，阻塞在下面的调用中，收到回复后接着执行下面的流程

RETRY_ON_EINTR(ret, read(s, &tid, ));

重新设置信号处理函数为SIG_DFL，即采取默认的动作

signal(n, SIG_DFL);

重新发送信号，进程从当前信号处理函数返回后，会处理这个信号，进行默认的信号处理动作，即中断进程。

logSignalSummary函数分析：

获取异常信号的名字和thread名字，并格式化字符串
调用函数__libc_android_log_write函数，用相关信息填充struct iovec vec[3]，此结构体数组的内容最终将写入log文件
函数__libc_android_log_write中，log_id为LOG_ID_MAIN，因此

log_channels[LOG_ID_MAIN] = { __write_to_log_init, -, "/dev/"LOGGER_LOG_MAIN }

log_channels[log_id].logger(log_id, vec)将调用__write_to_log_init
在函数__write_to_log_init中，log文件将写入”/dev/log/main”中，执行写log操作的函数是__write_to_log_kernel

3.Debuggerd 源码分析

debuggerd有两种启动方式：

在init进程中以deamon的方式启动，在init.rc中

service debuggerd /system/bin/debuggerd

class main

以这种方式启动的话，进入main函数后，将调用do_server函数，作为server端为其他进程提供dump进程信息的服务

直接运行system/bin/debuggerd可执行文件，需要指定参数，用法为

debuggerd -b [<tid>] //参数-b表示在控制台中输出backtrace

以这种方式启动的话，进入main函数后，将调用do_explicit_dump函数，与debuggerd daemon通信，将指定进程的信息dump到文件或控制台

Debuggerd框架图

do_server函数流程分析

(以daemon方式启动的时候将会进入这个函数)

1.为异常信号安装处理函数SIG_DFL，即忽略自身出现的错误问题 signal(SIGILL, SIG_DFL); signal(SIGABRT, SIG_DFL);

signal(SIGBUS, SIG_DFL);

signal(SIGFPE, SIG_DFL);

signal(SIGSEGV, SIG_DFL);

signal(SIGPIPE, SIG_DFL);

signal(SIGSTKFLT, SIG_DFL);

2. 调用下面的代码，建立socket通信的server端

s = socket_local_server(DEBUGGER_SOCKET_NAME,ANDROID_SOCKET_NAMESPACE_ABSTRACT, SOCK_STREAM);

3.进入无限循环中，等待连接请求，相关代码如下

 for(;;) {

        struct sockaddr addr;

        socklen_t alen;

        int fd;

        alen = sizeof(addr);

        fd = accept(s, &addr, &alen);

        if(fd < ) {

            continue;

        }

        fcntl(fd, F_SETFD, FD_CLOEXEC);

        handle_request(fd);

    }

最终调用handle_request处理socket上的请求

handle_request函数流程分析

1.调用read_request处理socket上由client端进程发送来的数据，处理流程为

<1.1>首先调用函数getsockopt给结构体变量ucred cr赋值

getsockopt(fd, SOL_SOCKET, SO_PEERCRED, &cr, &len);

ucred存储了socket的client端进程的pid uid gid

<1.2>从socket上读取debugger_msg_t结构体

<1.3> 给debugger_request_t* out_request 赋值

out_request->action = msg.action;

out_request->tid = msg.tid;

out_request->pid = cr.pid;

out_request->uid = cr.uid;

out_request->gid = cr.gid;

<1.4>如果debugger_msg_t中设置的action为DEBUGGER_ACTION_CRASH，说明是crash的C/C++进程发来的请求，则判断传进来的tid是否有效

<1.5>如果debugger_msg_t中设置的action为

DEBUGGER_ACTION_DUMP_BACKTRACE或者

DEBUGGER_ACTION_DUMP_BACKTRACE_TO_LOG

说明是其他方式(debuggerd/callstack)发来的请求，则要求必须为root权限或者system权限，然后再判断tid是否有效

2.从read_request返回后，调用ptrace函数attach由tid指定的进程，此时debuggerd将变为被attache进程的父进程，然后ptrace函数会向子进程发送SIGSTOP信号将子进程停下来。此时，父进程有机会检查子进程核心image和寄存器的值

3.调用下面的语句给client端子进程回复消息，使clinet端的进程能从read调用中返回

TEMP_FAILURE_RETRY(write(fd, "\0", )

4.在for循环中等待子进程停止

int signal = wait_for_signal(request.tid, &total_sleep_time_usec);

子进程收到SIGSTOP信号时，根据不同的action进行动作

if (request.action == DEBUGGER_ACTION_DUMP_TOMBSTONE) {

         tombstone_path = engrave_tombstone(request.pid, request.tid,

                                    signal, true, true, &detach_failed,

                                    &total_sleep_time_usec);

} else if (request.action == DEBUGGER_ACTION_DUMP_BACKTRACE) {

         dump_backtrace(fd, request.pid, request.tid, &detach_failed,

                                    &total_sleep_time_usec);

} else if (request.action == DEBUGGER_ACTION_DUMP_BACKTRACE_TO_LOG) {

         dump_backtrace_for_thread(fd, request.pid, request.tid, &detach_failed,

                                    &total_sleep_time_usec);

子进程收到七种异常信号时，调用函数engrave_tombstone进行处理 Notes：收到SIGSTOP说明与debuggerd通信的不是crash的进程，根据action不同将进程信息写入tombstone文件，或者写入socket文件并由相应的客户端进程会读取socket文件进行处理。收到七种异常信号说明是crash的进程，调用 engrave_tombstone直接将dump的信息写到tombstone文件中

5.调用ptrace(PTRACE_DETACH, request.tid, 0, 0)解除对子进程的追踪

6.调用kill(request.pid, SIGCONT)恢复被停止的子进程，并让其自然终止

关于attach_gdb的说明

1.如果运行了类似以下指令：

adb shell setprop debug.db.uid

则所有uid<10000的进程crash的时候attach_gdb为true，crash的进程将停止

2.调用ptrace(PTRACE_DETACH, request.tid, 0, 0) 解除对子进程的追踪后，开始等待gdb的连接

adb forward tcp: tcp:

adb shell gdbserver : --attach pid &

3.用户按下HOME或者VOLUME DOWN按键，可以使进程继续进行，自然crash 4.attach_gdb为false时，只会解除对子进程的追踪

engrave_tombstone函数流程分析

对于crash的C/C++进程，主要通过这个函数dump进程信息

1.创建”/data/tombstones”文件夹并修改权限

2.调用函数find_and_open_tombstone，tombstone_XX文件最多10个，超过则覆盖最早的

3.调用dump_crash将所有信息dump到tombstone文件

4.如果isSystemServerCrash(crash的进程是gaiad)或isSystemFinalizerTimeout为 true，则运行logcat命令将log缓冲区(/dev/log下的system,events ,radio,main文件)中的内容输出到tombstone文件中

dump_crash函数流程分析

1.dump_build_info(log)

dump “Build fingerprint”

2.dump_fault_addr(log, tid, signal) 调用ptrace(PTRACE_GETSIGINFO, tid, 0, &si)dump siginfo信息

3.dump_thread(context, log, tid, true, total_sleep_time_usec)

dump进程的上下文信息

4.dump_maps(log, pid)

dump /proc/pid/maps 中的信息

5.dump_smaps(log, pid)

dump /proc/pid/smaps 中的信息

6.dump_status(log, pid)

dump /proc/pid/status中的信息

7.dump_sibling_thread_report(context, log, pid, tid, total_sleep_time_usec)

do_explicit_dump函数流程分析

(在命令行中加参数启动的时候将进入这个函数)

判断dump_backtrace为true，调用dump_backtrace_to_file

(1) 调用socket_local_client与debuggerd deamon建立连接

(2) 给debugger_msg_t变量赋值，并发送给debuggerd

     debugger_msg_t msg;

     msg.tid = tid;

     msg.action = DEBUGGER_ACTION_DUMP_BACKTRACE;

(3)等待debuggerd 回复，并读取dump的信息，写入控制台中

 while ((n = TEMP_FAILURE_RETRY(read(s, buffer, sizeof(buffer)))) > ) {

                if (TEMP_FAILURE_RETRY(write(fd, buffer, n)) != n) {

                    result = -;

                    break;

                }

     }

判断dump_backtrace为false，调用dump_tombstone

(1) 调用socket_local_client与debuggerd deamon建立连接

(2) 给debugger_msg_t变量赋值，并发送给debuggerd

     debugger_msg_t msg;

     msg.tid = tid;

     msg.action = DEBUGGER_ACTION_DUMP_TOMBSTONE;

(3)等待debuggerd 回复，调用

TEMP_FAILURE_RETRY(read(s, pathbuf, pathlen - ))

这里和

handle_request的write(fd, tombstone_path, strlen(tombstone_path))

相互呼应 read读到的是tombstone_path，赋值给pathbuf后由do_explicit_dump调用

fprintf(stderr, "Tombstone written to: %s\n", tombstone_path)

输出