Android Tombstone 与Debuggerd 原理浅谈

一、前言

Android系统类问题主要有stability、performance、power、security。tombstoned是android平台的一个守护进程，它注册成3个socket服务端，客户端封装在crash_dump和debuggerd_client。 crash_dump用于跟踪定位C++ crash， debuggerd_client用于在某些场景（发生ANR，watchdog，shell执行debuggerd -b）dump指定进程 的backtrace。

二、tombstone原理

1，ELF程序加载过程

在进入execve()系统调用之后，Linux内核就开始进行真正的装配工作。在内核中，execve()系统调用相应的入口是sys_execve()。sys_execve()进行一些参数的检查复制之后，调用do_execve()。do_execve()会首先查找被执行的文件，如果找到文件，则读取文件的前128个字节。文件的前128个字节保存着可执行文件的格式信息，特别是前四个字节（魔数）。这样可以根据不同的可执行文件信息，来调用不同的装载模块。当do_execve()读取了这128个字节的文件头部之后，然后调用search_binary_handle()去搜索和匹配合适的可执行文件装载处理。linux中所有被支持的可执行文件格式都有相应的装载处理过程。search_binary_handle()会通过判断文件头部的魔数确定文件的格式，并且调用相应的过程。ELF可执行文件的装载处理过程叫做load_elf_binary()。load_elf_binary()被定义在fs/Binfmt_elf.c。它的主要步骤是：

1. 检查ELF可执行文件格式的有效性，比如魔数，程序头表中段（Segment）的数量

2. 寻找动态链接的“.interp”段，设置动态连接器路径（与动态链接有关）

3. 根据ELF可执行文件的程序头表的描述，对ELF文件进行映射，比如代码、数据、只读数据。

4. 初始化ELF进程环境，比如进程启动时EDX寄存器的地址应该是DT_FINI的地址。

5. 将系统调用的返回地址修改成ELF可执行文件的入口点，这个入口点取决于程序的链接方式，对于静态链接的ELF可执行文件，这个程序入口就是ELF文件的文件头中e_entry所指的地址；对于动态链接的ELF可执行文件，程序入口点是动态连接器。

当load_elf_binary()执行完毕，返回至do_execve()再返回到sys_execve()，上面的第5步中已经把系统调用的返回地址改成了被装载的ELF程序的入口地址了。所以当sys_execve()系统调用从内核态返回到用户态时，EIP寄存器存放下一个机器指令的地址, 直接跳转到了ELF程序的入口地址了，于是新的程序开始执行，ELF可执行文件装载完成。

在 execve() 执行过程中，系统会清掉 fork() 复制的原程序的页目录和页表项，并释放对应页面。系统仅为新加载的程序代码重新设置进程数据结构中的信息，申请和映射了命令行参数和环境参数块所占的内存页面，以及设置了执行代码执行点。此时内核并不从执行文件所在块设备上加载程序的代码和数据。当该过程返回时即开始执行新的程序，但一开始执行肯定会引起缺页异常中断发生。因为代码和数据还未被从块设备上读入内存。此时缺页异常处理程序会根据引起异常的线性地址在主内存区为新程序申请内存页面（内存帧），并从块设备上读入引起异常的指定页面。同时还为该线性地址设置对应的页目录项和页表项。这种加载执行文件的方法称为需求加载（Load on demand）。

2，Android Linker

无 --dynamic-linker编译参数的ELF文件会加载为静态可执行程序，如init进程:

Android大部分可执行程序使用linker做动态连接器，编译时候加上参数 --dynamic-linker

除了init进程，recovery，adbd进程也没有配置--dynamic-linker链接器。他们在Android.mk里面声明LOCAL_FORCE_STATIC_EXECUTABLE := true或者在Android.bp声明static_executable: true。静态可执行程序不能加载libc等动态库，只能导入static_libs。以上都是针对ELF格式的程序。

当然，/system/bin/linker也是静态连接的。他自己不能配置为动态链接器。Linker的Android.bp里面配置static_executable: true。同时根据arch编译汇编代码 begin.S来配置程序入口。Arm64汇编指令 bl:跳转指令,但是在跳转之前,会将下一条指令保存到返回地址(链接寄存器）LR寄存器中。Br与bl类似，只是后面参数需要特定的寄存器。

3，Android Linker 拦截信号

应用程序注册信号处理hanlder，当信号事件发生后，内核将信号置为pending状态，在中断返回或者系统调用返回时，查看pending的信号，内核在应用程序的栈上构建一个信号处理栈帧，然后通过中断返回或者系统调用返回到用户态，执行信号处理函数。执行信号处理函数之后，再次通过sigreturn系统调用返回到内核，在内核中再次返回到应用程序被中断打断的地方或者系统调用返回的地方接着运行。 

debuggerd_signal_handler()函数最开始使用互斥锁 pthread_mutex_lock() 来保护线程，方式同一时间多个线程处理信号而导致冲突。接着，调用 log_signal_summary() 来输出一些log 信息信息，例如fault addr、signo、signame、pid、tid、线程名、主线程名等。

接着，调用clone() 函数创建伪线程，并在伪线程中调用 debuggerd_dispatch_pseudothread() 函数，原来的线程原地等待子线程的开始和结束。

如果应用程序没有注册对应的信号处理函数，那么信号发生后，内核按照内核默认的信号处理方式处理该信号。

debuggerd_dispatch_pseudothread() 线程中会 fork 一个子进程，并通过 execle() 系统调用去执行 crash_dump64 程序，父进程等待 crash_dump64 进程退出。

4，LINUX信号

当程序运行出现异常时候，CPU会发出指令异常信号。非可靠信号，由linker注册。Linker加载的动态可执行程序，即使被加载程序调用了注册函数函数，也不能正常收到，因为这些信号已经提前被被linker截断。

中断信号的产生有以下4个来源：1,外设(来自中断控制器); 2,IPI(处理器间中断); 3, CPU异常（比如前一条指令存在除零错误、缺页错误等）; 4,中断指令。前两种中断都可以叫做硬件中断，都是异步的；后两种中断都可以叫做软件中断，都是同步的。在arm64架构加，将上述中断分类为异步异常（Physical interrupts和Virtual interrupts）和同步异常（同步异常与当前指令的执行直接相关）。其实大同小异。以上是CPU层面的，对于LINUX来说，以上描述的异常或者中断，都代表一次hardirq。当然hardirq可能产生一个softirq到软中断pending列表，或者直接被处理返回。Linux的软中断是进程调度层面的，由内核线程softirqd去读取软中断pending列表，再转化为信号分发。当一个进程收到一个信号的时候，进程会被挂起，开始执行中断处理函数。Linux操作系统当中有62个信号，前31个（1-31）：不可靠信号，非实时信号，信号有可能丢失，后31个（34-64）：可靠信号，信号不会丢失。非可靠信号注册多次，只会处理第一次注册的，可靠信号注册多次，会处理多次。Linux处理软中断处于程序上下文。处理硬中断处于中断上下文。

5，crash dump流程

在 crash_dump64 进程中，再fork 一个新进程，父进程通过 fork_exit_read 去等待子进程，子进程继续执行 crash_dump 的任务。

在 crash_dump64 中，通过 /proc/PID/cmdline 获取进程的名字，通过 /proc/PID/fd 获取此进程打开多少文件，每个文件都有一个描述符。

在 crash_dump64 中循环遍历这个进程中所有的线程，对进程中的每一个线程进行 ptrace 操作，对目标线程读取器 crashinfo。crashinfo 读取完毕后 detech 当前的线程。

之后，在 crash_dump64 中调用 tombstoned_connect() 通过 socket 连接到 tombstoned 进程。根据 signal 的 si_val 的值做不同的判断，为0时 dump tombstone，为1时 dump backtrace。

如果是 dump tombstone，最终 tombstone 通过 engrave_tombstone() 函数生成，engrave_tombstone() 函数的第二个参数 unwinder 是输出 backtrace 等信息的关键函数。unwinder 初始化过程中获取了当前进程的内存和 memory map，这些信息会在后面帮助 debuggerd 生成 tombstone 文件。

6，debug dump trace 流程

Debug dump的触发场景一般是system_server发生watch dog，或者系统执行“debuggerd –b [pid]”命令产生。分别是调用进程加载组件debuggerd_client的接口:
dump_backtrace_to_file(), 
或者JNI接口:
android_os_Debug_dumpJavaBacktraceToFileTimeout(), android_os_Debug_dumpNativeBacktraceToFileTimeout()。
信号会对系统调用产生影响，触发系统调用的自动重启动。

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

然后向目标进程发送信号signal = (dump_type == kDebuggerdJavaBacktrace) ? SIGQUIT : DEBUGGER_SIGNAL;  --- #define DEBUGGER_SIGNAL (__SIGRTMIN + 3)。

之后等待tombstoned的信息返回。

7，Crash dump与debug dump整体流程

异常发生时, ARM 处理器会跳转到对应该异常的 固定地址 去执行异常处理程序, 这个 固定的地址 就是异常向量。对于tombstone类异常，会产生一个Software interrupt (SWI)。每个cpu会有一个内核线程softirqd轮询读取软中断，并把信号转发给对应的应用。除了SWI，ARM还会产生Reset，Undefined instructions，Prefetch Abort (instruction fetch memory abort) ，Data Abort (data access memory abort)，IRQ (interrupt)以及FIQ (fast interrupt)。Arm64会产生：Synchronous exception，Serror，IRQ， FIQ四个类型的同步异常。不同架构中断与异常代码流程底层差异比较大。除了底层上报，还有各个应用程序可以给其他应用发送信号，由操作系统调度。

三、LOG解析

1，debugdump

一般问题不会是libc.so或者libhwbinder.so这种经过多年检验的公共库。找到与问题版本对应的符号产物。本地复现的在符号在out/ 目录里 symbols/ 目录下（或者在编译后的工程先source 和lunch之后再用addr2line ）

addr2line -f –a -C -e

./symbols/vendor/bin/hw/android.hardware.audio@2.0-service  00001771

2，crashdump

四、示例

1，权限问题导致SIGABRT

检查main log，有如下selinux打印：

07-18 17:48:44.679  6105  6105 W Binder:6105_2: type=1400 audit(0.0:3532): avc: denied { read write } for name="hab" dev="tmpfs" ino=15391 scontext=u:r:shell:s0 tcontext=u:object_r:hab_device:s0 tclass=chr_file permissive=0
07-18 17:48:44.691  6105  6114 I Adreno-GSL_RPC: <gsl_rpc_connect:1211>: connecting using conn_id 0
07-18 17:48:44.692  6105  6114 I uhab    : habmm_socket_open: hab: open failed, error code 13 Permission denied
07-18 17:48:44.692  6105  6114 E Adreno-GSL_RPC: <gsl_hab_open:51>: Unable to habmm_socket_open err -13

后来修改：

allow shell hab_device:chr_file_rw_file_perms;

2，线程时序导致空指针异常

pid: 1082, tid: 1534, name: HwBinder:1082_1  >>> /system/vendor/bin/ipacm <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8
Cause: null pointer dereference
    x0  0000000000000000  x1  0000000000000000  x2  6c206b636172746e  x3  0a2e646165726874
    x4  2072656e65747369  x5  000000719b41d399  x6  20746f4720202928  x7  7364662068746f62
    x8  edf87d25729f7502  x9  edf87d25729f7502  x10 0000000000004001  x11 0000000000000000
    x12 656e657473696c20  x13 000000000000009a  x14 0000000000000000  x15 000000719b98e3f8
    x16 000000719beb11e0  x17 000000719be44950  x18 0000000000000001  x19 0000000000000000
    x20 000000719b98f588  x21 0000000000000006  x22 000000719b98f588  x23 000000719b4327a8
    x24 000000719b48f000  x25 0000005fcc052680  x26 0000000000000000  x27 000000719b98f588
    x28 0000000000000000  x29 000000719b98e440
    sp  000000719b98e410  lr  0000005fcc052908  pc  0000005fcc0500c4

backtrace:
    #00 pc 00000000000330c4  /vendor/bin/ipacm (IPACM_ConntrackListener::CreateConnTrackThreads()+36)
    #01 pc 0000000000035904  /vendor/bin/ipacm (IPACM_OffloadManager::provideFd(int, unsigned int)+644)
    #02 pc 000000000000a1d8  /vendor/lib64/liboffloadhal.so (HAL::setHandles(android::hardware::hidl_handle const&, android::hardware::hidl_handle const&, std::__1::function<void (bool, android::hardware::hidl_string const&)>)+420)
    #03 pc 000000000000ceec  /system/lib64/vndk-28/android.hardware.tetheroffload.config@1.0.so (android::hardware::tetheroffload::config::V1_0::BnHwOffloadConfig::_hidl_setHandles(android::hidl::base::V1_0::BnHwBase*, android::hardware::Parcel const&, android::hardware::Parcel*, std::__1::function<void (android::hardware::Parcel&)>)+316)
    #04 pc 000000000000d1a0  /system/lib64/vndk-28/android.hardware.tetheroffload.config@1.0.so (android::hardware::tetheroffload::config::V1_0::BnHwOffloadConfig::onTransact(unsigned int, android::hardware::Parcel const&, android::hardware::Parcel*, unsigned int, std::__1::function<void (android::hardware::Parcel&)>)+320)
    #05 pc 000000000001d334  /system/lib64/vndk-sp-28/libhwbinder.so (android::hardware::IPCThreadState::executeCommand(int)+640)
    #06 pc 000000000001430c  /system/lib64/vndk-sp-28/libhwbinder.so (android::hardware::IPCThreadState::getAndExecuteCommand()+196)
    #07 pc 0000000000014588  /system/lib64/vndk-sp-28/libhwbinder.so (android::hardware::IPCThreadState::joinThreadPool(bool)+268)
    #08 pc 000000000001c1ac  /system/lib64/vndk-sp-28/libhwbinder.so (android::hardware::PoolThread::threadLoop()+24)
    #09 pc 000000000000fa08  /system/lib64/vndk-sp-28/libutils.so (android::Thread::_threadLoop(void*)+280)
    #10 pc 00000000000819b4  /system/lib64/libc.so (__pthread_start(void*)+36)
    #11 pc 0000000000023478  /system/lib64/libc.so (__start_thread+68)

具体代码就不多贴了，直接贴修改，就懂了。 

3，libart 出现BUS_ADRALN

pid: 2147, tid: 2147, name: m.app.animation  >>> com.app.animation <<<
signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0x656c62
    x0  0000006f90ee8648  x1  0000000041504e4d  x2  0000007ff0cf5be8  x3  0000006f90668ed8
    x4  0000000012c12da6  x5  0000007ff0cf5c46  x6  6f00630015000000  x7  770067002e006d00
    x8  0000000000656c62  x9  0000006f90e4b700  x10 0000000000000032  x11 69006e0061002e00
    x12 6900740061006d00  x13 000000006e006f00  x14 0000000070ca1348  x15 0000000000003eba
    x16 0000006f90714140  x17 000000701265db30  x18 0000000000000000  x19 0000007ff0cf5be8
    x20 0000000041504e4d  x21 0000006f90e2b6f8  x22 0000006f90e2b6f8  x23 0000007ff0cf6088
    x24 0000007ff0cf5c14  x25 00000070168895e0  x26 000000007090b600  x27 0000000071178cb0
    x28 0000000012c12c20  x29 0000007ff0cf5bd0
    sp  0000007ff0cf5bb0  lr  0000006f90558a30  pc  0000000000656c62

backtrace:
    #00 pc 0000000000656c62  <unknown>
    #01 pc 0000000000473a2c  /system/lib64/libart.so (art::RuntimeCallbacks::DdmPublishChunk(unsigned int, art::ArrayRef<unsigned char const> const&)+56)
    #02 pc 00000000003f0f14  /system/lib64/libart.so (art::DdmServer_nativeSendChunk(_JNIEnv*, _jclass*, int, _jbyteArray*, int, int)+356)
    #03 pc 000000000007fb74  /system/framework/arm64/boot-core-libart.oat (offset 0x79000) (org.apache.harmony.dalvik.ddmc.DdmServer.nativeSendChunk+196)
    #04 pc 000000000013e9bc  /system/framework/arm64/boot-core-libart.oat (offset 0x79000) (org.apache.harmony.dalvik.ddmc.DdmServer.sendChunk+76)
    #05 pc 00000000007e92ac  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.ddm.DdmHandleAppName.sendAPNM+284)
    #06 pc 0000000000879a78  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.app.ActivityThread.handleBindApplication+952)
    #07 pc 0000000000876034  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.app.ActivityThread$H.handleMessage+6916)
    #08 pc 0000000000ab7724  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.os.Handler.dispatchMessage+180)
    #09 pc 0000000000aba820  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.os.Looper.loop+1264)
    #10 pc 0000000000882e28  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.app.ActivityThread.main+664)
    #11 pc 0000000000554c4c  /system/lib64/libart.so (art_quick_invoke_static_stub+604)
    #12 pc 00000000000cf6e8  /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+232)
    #13 pc 000000000045c840  /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
    #14 pc 000000000045e294  /system/lib64/libart.so (art::InvokeMethod(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jobject*, _jobject*, unsigned long)+1440)
    #15 pc 00000000003ee1d4  /system/lib64/libart.so (art::Method_invoke(_JNIEnv*, _jobject*, _jobject*, _jobjectArray*)+52)
    #16 pc 000000000011e6d4  /system/framework/arm64/boot-core-oj.oat (offset 0x114000) (java.lang.Class.getDeclaredMethodInternal [DEDUPED]+180)
    #17 pc 0000000000bf1bd8  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run+136)
    #18 pc 0000000000bf8dc0  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (com.android.internal.os.ZygoteInit.main+3088)
    #19 pc 0000000000554c4c  /system/lib64/libart.so (art_quick_invoke_static_stub+604)
    #20 pc 00000000000cf6e8  /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+232)
    #21 pc 000000000045c840  /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
    #22 pc 000000000045c4a0  /system/lib64/libart.so (art::InvokeWithVarArgs(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, std::__va_list)+424)
    #23 pc 0000000000361b60  /system/lib64/libart.so (art::JNI::CallStaticVoidMethodV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list)+652)
    #24 pc 00000000000b2374  /system/lib64/libandroid_runtime.so (_JNIEnv::CallStaticVoidMethod(_jclass*, _jmethodID*, ...)+120)
    #25 pc 00000000000b4cf8  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::start(char const*, android::Vector<android::String8> const&, bool)+756)
    #26 pc 000000000000219c  /system/bin/app_process64 (main+1200)
    #27 pc 00000000000acac8  /system/lib64/libc.so (__libc_init+88)

由于每次异常打印的异常地址都是 fault addr 0x656c62，且多个应用都有打印，说明该问题是libart.so强相关，而不是com.app.animation的内存问题。地址0x656c62固定，有可能两种情况，一种是代码中存在字节不对齐情况，一种是这个地址是相对于对象首地址的偏移地址，这是对象被释放后的解引用。

出现的原因是adbd守护进程会因为开机阶段多次重新配置usb模式而被多次杀掉重新启动。如果杀掉重新启动adbd的时候正好碰上zygote孵化进程，某些进程就有概率报告这个错误。

解决方法：

Android12没有该问题。Android12上面gState与this_指针没有delete, 他们使用C++17的std::optional<>模板，无new与delete。

4，system_server 调用 debug dump导致audio crash

pid: 568, tid: 592, name: HwBinder:568_1  >>> /vendor/bin/hw/vendor.fiill.hardware.automotive.audiocontrol@1.0-service <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'Status.cpp:142] Attempted to retrieve value from failed HIDL call: Status(EX_TRANSACTION_FAILED): 'DEAD_OBJECT: ''

pid: 27420, tid: 27437, name: HwBinder:27420_  >>> /vendor/bin/hw/vendor.fiill.hardware.automotive.audiocontrol@1.0-service <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'Status.cpp:142] Attempted to retrieve value from failed HIDL call: Status(EX_TRANSACTION_FAILED): 'DEAD_OBJECT: ''

 这个问题出现多个tombstone，先从后面的tombstone_6, tombstone_7看，他们出错的问题相同，都是DEAD_OBJECT。从main log看，问题之前27216 进程退出了。连坐了audioserver与vendor.audio-hal。

01-01 10:29:55.035     0     0 I [kernel]init: Untracked pid 27216 exited with status 0
01-01 10:29:55.035     0     0 I [kernel]init: Service 'audioserver' (pid 677) received signal 6
01-01 10:29:55.035     0     0 I [kernel]init: Sending signal 9 to service 'audioserver' (pid 677) process group...
01-01 10:29:55.035     0     0 I [kernel]libprocessgroup: Successfully killed process cgroup uid 1041 pid 677 in 0ms
01-01 10:29:55.035     0     0 I [kernel]init: Sending signal 9 to service 'vendor.audio-hal-2-0' (pid 532) process group...
01-01 10:29:55.054     0     0 I [kernel]libprocessgroup: Successfully killed process cgroup uid 0 pid 532 in 18ms

进程 27216是进程677 audioserver fork出来打印dump的。 Tombstone_5打印的是一个audioserver一个线程的主动abort。分析是某些audioflinger的接口被调用后，规定时间没有返回，就会出现问题。通过代码走读， 确认当前问题是audioflinger调用服务端的一个接口卡住了。服务端是android.hardware.audio@2.0-service

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

pid: 677, tid: 1212, name: TimeCheckThread  >>> /system/bin/audioserver <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'TimeCheck timeout for IAudioFlinger: 2'
    r0  00000000  r1  000004bc  r2  00000006  r3  ec167830
    r4  000002a5  r5  000004bc  r6  e8bc14a4  r7  0000010c
    r8  ddf0776c  r9  eae9f1e8  r10 3b9aca00  r11 ec5e1d69
    ip  7fffffff  sp  e8bc1490  lr  ec0f3105  pc  ec0eae92

backtrace:
    #00 pc 0001ce92  /system/lib/libc.so (abort+62)
    #01 pc 00006dd5  /system/lib/liblog.so (__android_log_assert+156)
    #02 pc 0000e233  /system/lib/libmedia_helper.so (android::TimeCheck::TimeCheckThread::threadLoop()+270)
    #03 pc 0000c1bf  /system/lib/libutils.so (android::Thread::_threadLoop(void*)+286)
    #04 pc 00063c85  /system/lib/libc.so (__pthread_start(void*)+22)
    #05 pc 0001e085  /system/lib/libc.so (__start_thread+22)

如果要确认对端是谁，则可以通过如下命令打开binder的transaction调试后重新复现：

echo 512 > /sys/module/binder/parameters/debug_mask

也可在现场打印：

cat /d/binder/transaction_log

查看进程532有个dump信息在tombstone_3。怀疑是这个进程崩溃，或者被dump。如果被dump会让正在系统调用直接结束。会让binder客户端就一直等不到返回。如果进程崩溃，binder客户端可能返回错误死亡，也可能长时间卡住。

----- pid 532 at 2023-10-11 03:57:05 -----
Cmd line: /vendor/bin/hw/android.hardware.audio@2.0-service
ABI: 'arm'

"audio@2.0-servi" sysTid=532
  #00 pc 00053f7c  /system/lib/libc.so (__ioctl+8)
  #01 pc 00021c31  /system/lib/libc.so (ioctl+36)
  #02 pc 00015ccf  /system/lib/vndk-sp-28/libhwbinder.so (android::hardware::IPCThreadState::talkWithDriver(bool)+190)
  #03 pc 0000ef93  /system/lib/vndk-sp-28/libhwbinder.so (android::hardware::IPCThreadState::getAndExecuteCommand()+10)
  #04 pc 0000f21d  /system/lib/vndk-sp-28/libhwbinder.so (android::hardware::IPCThreadState::joinThreadPool(bool)+188)
  #05 pc 00001771  /vendor/bin/hw/android.hardware.audio@2.0-service (main+480)
  #06 pc 0008bdf9  /system/lib/libc.so (__libc_init+48)
  #07 pc 0000156f  /vendor/bin/hw/android.hardware.audio@2.0-service (_start_main+46)
  #08 pc 00018037  /system/bin/linker (__dl__ZN6soinfoD1Ev+14)
  #09 pc 00020a01  [stack:ffe44000]

在mainlog中检查这个进程被dump，并没有奔溃：

10-11 03:57:05.698 27143 27143 I crash_dump32: performing dump of process 532 (target tid = 532)

 再往前查找这个dump动作，发现是system_server进程触发的：

10-11 03:56:55.167   931   931 I /system/bin/tombstoned: received crash request for pid 1024
10-11 03:56:55.168   931   931 I /system/bin/tombstoned: found intercept fd 512 for pid 1024 and type kDebuggerdJavaBacktrace
10-11 03:56:55.168  1024  1029 I system_server: Wrote stack traces to '[tombstoned]'
10-11 03:56:55.193  1024  1461 I system_server: libdebuggerd_client: done dumping process 1024

根据AMS的代码流程，如果JAVA backtrace dump失败了，则会dumpNativeBacktrace。

6320    private static long dumpJavaTracesTombstoned(int pid, String fileName, long timeoutMs) {
6321        final long timeStart = SystemClock.elapsedRealtime();
6322        if (!Debug.dumpJavaBacktraceToFileTimeout(pid, fileName, (int) (timeoutMs / 1000))) {
6323            Debug.dumpNativeBacktraceToFileTimeout(pid, fileName,
6324                    (NATIVE_DUMP_TIMEOUT_MS / 1000));
6325        }
6326
6327        return SystemClock.elapsedRealtime() - timeStart;
6328    }

触发JAVA backtrace dump的原因，有发生ANR，watch dog等。不再讨论。

5，关于dump

早期的UNIX系统的一个特性：如果进程在执行一个低速系统调用而阻塞期间，捕捉到一个信号，则该系统调用就被中断而不再继续执行。该系统调用返回出错，其error被设置为EINTR。即信号中断系统调用的执行。
这样处理的理由是：因为一个信号发生了，进程捕捉到了它，那么意味着已经发生了某种事情，所以是个唤醒 被阻塞的系统调用 的机会。
为了支持系统调用被信号打断而不再执行的特性，将系统调用分为两类：低速系统调用和其他系统调用。
低速系统调用是可能会使进程永远阻塞的一类系统调用，他们包括：
1. read()、readv(),在读某些类型的文件(管道、终端设备以及网络设备)时，如果数据并不存在则可能会使调用者永远阻塞；
2. write()、writev()，在写这些类型的文件时，如果不能立即接受这些数据，则也可能会使调用者永远阻塞；
3. 打开某些类型的文件，在某种条件发生之前也可能会使调用者阻塞(例如，打开终端设备，他要等待直到所连接的调制解调器应答了电话)--->这种类型还没有实际例子测试
4. pause()和wait();
5. 某些ioctl;
6. 某些进程间通信函数;

什么是系统调用的自动重启动？
　　当系统调用被信号中断时，并不返回，而是继续执行。如果read()阻塞等待，当进程接受到信号时，并不将read返回，而是继续阻塞等待。
为什么要引入自动重启动的？
　　有时用户并不知道所使用的输入、输出设备是否是低速设备。如果编写的程序可以用交互方式运行，则他可能读、写低速终端设备。
　　如果在程序中捕捉到信号，而系统调用并不提供重启动功能，则对每次读、写系统调用都要进行是否出错返回的测试，如果是被信号中断，则再调用读、写系统调用。
什么时候引入系统调用的自动重启动？
　　4.2BSD支持某些被中断系统调用的自动重启动。
　　4.3BSD允许进程基于每个信号禁用自动重启动功能(因为也存在某些应用程序并不希望系统调用被中断后自动重启)

默认自动重启动的系统调用包括：ioctl(),read(),readv(),write(),writev(),wait(),waitpid();其中前5个函数只有在对低速设备进行操作时才会被信号中断。而wait和waitpid在捕捉到信号时总是被中断。

Binder驱动不使用read()、write()函数，系统调用接口是ioctl()。

五、其他

1，严格编码规范降低tombstone概率

如下这段代码改编自某雷。该模块经常出现一些莫名奇妙、最后死在libc或者libc++的墓碑。这段代码即便在已经精简到这几行，调试运行时候也不一定报异常。

#include<stdio.h>
#include<string.h>
#include<stdlib.h>
#define DEFAULT_SIZE 10

int main(int args, char** argv){
    int total_size = 0;
    char * buf = NULL, * data = NULL;
    if(args >= 2) {
        data = argv[1];
    } else {
        return -1;
    }

    total_size = DEFAULT_SIZE +
        strlen(data) > 7 ? strlen(data) : 0;

    buf = (char*)malloc(total_size);
    strcpy(buf, "D:");
    strcpy(buf + strlen(buf), data);
    free(buf);
    return 0;
}

使用墓碑文件、gdb、trace32 等是无力排查此类问题的。这种踩内存问题，最有效的定位方法是使用ASAN。问题定位实际上已经算个比较坏的情况了。更好的情况还是什么定位都不发生。最有效避免此类tombstone的方法是严格执行编码规范。

ryan@QNXAnd-Srv07:~/asan$ gcc mem.cpp
ryan@QNXAnd-Srv07:~/asan$ ./a.out 123123
ryan@QNXAnd-Srv07:~/asan$ gcc -fsanitize=address mem.cpp
ryan@QNXAnd-Srv07:~/asan$ ./a.out 123123
=================================================================
==53122== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60040000dff2 at pc 0x7fa97aa93755 bp 0x7ffc54803a50 sp 0x7ffc54803210
WRITE of size 7 at 0x60040000dff2 thread T0

2，使用ASAN

如下是一个高通8295平台的一个patch:

From 7c3983c6602464915e601d40b8e5cb8f3d8696e2 Mon Sep 17 00:00:00 2001
From: xuvdovyangv <xuvdovyangv@qti.qualcomm.com>
Date: Mon, 31 Oct 2022 15:11:48 +0800
Subject: [PATCH] hypv-intercept: fix intercept crash for pointor of stack

The pollFds passed to close thread are created on the stack of the poll thread
of QC2V4l2Driver.
In some time sequence, when C2 poll thread is quickly closed -- before
close thread visiting the pollFds -- pollFds of close thread will be an wild pointer,
resulting SEGV_ACCERR.

Change-Id: I30515d4778bdb1a06f8dd7734ddc67ff21ba7125
---
 hyp-video-intercept/hyp_video_intercept.cpp | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/hyp-video-intercept/hyp_video_intercept.cpp b/hyp-video-intercept/hyp_video_intercept.cpp
index 81f5508..f2eb8fc 100644
--- a/hyp-video-intercept/hyp_video_intercept.cpp
+++ b/hyp-video-intercept/hyp_video_intercept.cpp
@@ -387,6 +387,9 @@ static void* close_thread(void *fds)
             pthread_cond_signal(&handle->cond);
         }
     }
+
+    delete pfds;
+
     return NULL;
 }
 
@@ -418,7 +421,15 @@ int hyp_video_poll(struct pollfd *fds, nfds_t nfds, int timeout)
             fds[1].revents = fds[0].revents = 0;
 
             if (handle->thread_id == 0) {
-                if (pthread_create(&handle->thread_id, 0, close_thread, fds)) {
+                struct pollfd *pfds = new struct pollfd[2];
+                if (pfds == nullptr) {
+                    HYP_VIDEO_MSG_ERROR("failed to new pollfd[2]");
+                    return -1;
+                }
+                pfds[0].fd = fds[0].fd;
+                pfds[1].fd = fds[1].fd;
+
+                if (pthread_create(&handle->thread_id, 0, close_thread, pfds)) {
                     handle->thread_id = 0;
                     return -1;
                 }
-- 
2.7.4

吸收一下他们的算法:

#include<pthread.h>
#include <unistd.h>

struct pollfd {
    int fd;
    char* data;
};

static void* close_thread(void* fds) {
    struct pollfd *pfds = (struct pollfd *)fds;
    delete pfds;
    return NULL;
}

int main(int args, char** argv){
    pthread_t thread_id;
    struct pollfd *pfds = new struct pollfd[2];
    if (pthread_create(&thread_id, 0,
          close_thread, pfds)) {
       return -1;
    }
    // pthread_join(thread_id, NULL);
    sleep(3);
    return 0;
}

运行调试一下：

以上代码，如果不加-fsanitize=address是检查不出来问题的。 

ryan@QNXAnd-Srv07:~/asan$ g++ delete.cpp -o delete -lpthread
ryan@QNXAnd-Srv07:~/asan$ ./delete
ryan@QNXAnd-Srv07:~/asan$