【Android论文栏目提醒】:网学会员,鉴于大家对Android论文十分关注,论文会员在此为大家搜集整理了“Android Debuggerd的分析及使用方法 - 学士论文”一文,供大家参考学习!
Android Debuggerd 的分析及使用方法
Android 系统自带一个实用的程序异常退出的诊断 daemon debuggerd。
此进程可以侦测到程序崩溃,并将崩溃时的进程状态信息输出到文件和串口中,以供开发人员分析调试使用。
Debuggerd 的数据,被保存在 /data/tombstone/ 目录下名字取的也很形象,tombstone 是墓碑的意思,共可保存 10 个文件,当超过 10 个时,会覆盖重写最早生产的文件。
串口中,则直接用 DEBUG 的 tag,输出 logcat 信息。
信息详解Debuggerd 的输出格式大约如下:I/DEBUG 9114: I/DEBUG 9114: Build fingerprint:generic/gs701b/gs701b:4.0.3/IML74K/eng.andy.xia.20120827.120650:user/test-keysI/DEBUG 9114: pid: 11053 tid: 11065 net.osaris.turbofly 0 usleep100 1000 continue LOGtimed out reading tidn goto done LOGread failure sn strerrorerrno goto done 读取客户端送过的 tid,tid 是标明那个线程 ID 执行中遇到错误了,debuggerd 就专门针对该线程 dump 出其寄存器、backtrace 和栈信息以供调试。
tid_attach_status ptracePTRACE_ATTACH tid 0 0 这里,debuggerd 就挂上 ptrace 了,attach 到出问题的线程,这样 debuggerd 就可以控制tid 线程了。
ptrace 的实现,attach 上之后,debuggerd 进程就是被调试进程的父进程了,PTRACE_ATTACH 会向被调试进程发送 SIGSTOP。
if TEMP_FAILURE_RETRYwritefd tid 1 1 XLOGfailed responding to client: sn strerrorerrno goto done 由于之前,在目标进程的 signal 处理函数中,是堵在 socket 的 read 中这样做是等待被debuggerd 响 应 到 , 这 里 写 一 下, 则 read 可 以 读 到 数 据 , 等 待 结 束, 之后 如 果 使 用PTRACE_CONT 的话,被调线程可以继续执行。
接下来,就是在一个 for 循环中 waitpid 了。
n waitpidtid status __WALL WNOHANG 由于 option 是 WNOHANG, 这个 wait 并不阻塞, Wait 到之后,就需要看一下状态: ifWIFSTOPPEDstatus n WSTOPSIGstatus switchn case SIGSTOP: XLOGstopped -- continuingn n ptracePTRACE_CONT tid 0 0 ifn LOGptrace failed: sn strerrorerrno goto done continue case SIGILL: case SIGABRT: case SIGBUS: case SIGFPE: case SIGSEGV: ifdef SIGSTKFLT case SIGSTKFLT: endif case SIGPIPE: XLOGstopped -- fatal signaln need_cleanup engrave_tombstonecr.pid tid debug_uid n killtid SIGSTOP goto done default: XLOGstopped -- unexpected signaln goto done else XLOGunexpected waitpid responsen goto done 这里查看 wait 的被调试进程的 signal 状态,如果是 SIG_STOP,则继续,其他几个异常signal,则调用 need_cleanup engrave_tombstonecr.pid tid debug_uid n这块是 debuggerd 最核心的部分:生产 tombstone 的调试信息。
Tombstone 的生成过程整个 debuggerd 的工作流程如下图:1. Mips 的栈帧结构简介2. 问题分析及定位方法3. 有用的信息Debuggerd 除了会在进程异常时产生 tombstone 外,还可以协助我们 debug 这个进程。
使用方法是:在串口中,设置需要 debug 的应用程序的 uid 后,如果这个程序出现异常,即可挂上 gdb 调试。
Android uid 的规则,所有 zygote 启动的 app,都是 从 10000 开始,比如 ps 时,看到一个 app叫 app_23, 则可以设置: setprop debug.db.uid 10023,即可 debug 此进程。
对于一些库,可能没有符号信息,这样在 tombsotne 中打印的 trace,很难查看具体出错的函数,可以通过在该库模块的编译选项中,注释掉,重编编译,即可得到带符号信息的库。