addr2line + objdump 定位crash问题

当动态链接的可执行文件启动时，系统会注册多个信号处理程序，如果出现崩溃，这些处理程序会将一份基本崩溃转储信息写入 logcat，并将一个更详细的 Tombstone 文件写入 /data/tombstones/。具体而言，该文件包含崩溃进程中所有线程（而不只是捕捉到信号的线程）的堆栈轨迹、完整的内存映射，以及所有打开的文件描述符的列表。详细可以参考如下链接：https://source.android.com/docs/core/tests/debug?hl=zh-cn#debuggerd

ARM平台汇编知识

寄存器介绍

1. x0-x29为通用寄存器，运算、入参、返回值传递等过程都会用到。

AArch64 Register and Instruction Quick Start - CDOT Wiki

2. lr (Link Register)寄存器保存函数的返回地址，即一个函数调用完成后跳转回父函数，需要继续执行父函数中的指令的地址。有时也表示为x30寄存器。

3. sp (Stack Pointer)寄存器保存栈指针。

4. pc (Program Counter)寄存器保存当前正在执行的指令的地址，指令执行完后会更新为将要执行的下一条指令的地址。

5. pst (Program Status Register)程序状态寄存器，是一组用于记录处理器状态和控制处理器行为的位字段。

6. wzr/xzr ：32位/64位的零寄存器。

常见汇编指令

1. ldr (load register)：内存中的值保存到寄存器中，ldr w8, [sp, #12] 的作用是把栈上sp+12位置的值保存到w8寄存器中。

2. str (store register)：寄存器中的值保存到内存里，str wzr, [sp, #12] 的作用是把32位零寄存器的值写入到栈上sp+12的位置。

3. add：加法运算，add w8, w8, w9 的作用是把w8 + w9的计算结果储存到w8中。

4. sub：减法运算:，sub sp, sp, #16 的作用是把sp-16的计算结果储存到sp中（移动栈指针）。

5. ret：执行此指令将跳转回lr寄存器中保存的地址。

6. bl：将此指令的顺序下一条指令地址保存到lr寄存器，并跳转到指定地址。

7. mov：寄存器间的值移动，或存储立即数到寄存器。

下面来看一个简单例子：main调用函数FuncA，在FuncA中做了一个加法并返回结果，保存在main函数栈上的res中。（clang -O0)

逐条解释汇编代码：

FuncA():                              // @FuncA()
        sub     sp, sp, #16         //开辟FuncA()栈空间  
        str     wzr, [sp, #12]  //将0保存在，栈空间 sp+12 位置处
        mov     w8, #1          //将1存到w8寄存器中      // =0x1
        str     w8, [sp, #8]    //将w8寄存器中的值，保存在 sp+8 位置处
        ldr     w8, [sp, #12]  //将栈上内存位置为sp+12的值 ，读到w8中
        ldr     w9, [sp, #8]  //将栈上内存位置为sp+8的值 ，读到w9中
        add     w8, w8, w9    //w8寄存器中值 + w9寄存器中的值 保存到 w8中
        str     w8, [sp, #4]  //将w8寄存器中的值，保存到栈上 sp+4的位置上
        ldr     w0, [sp, #4]  //将栈上sp+4的值，保存到 w0寄存器中
        add     sp, sp, #16   //退栈，归还 FuncA函数栈空间
        ret                   //返回
main:                                   // @main
        sub     sp, sp, #32           //开辟main函数栈空间
        stp     x29, x30, [sp, #16]  //存储栈帧操作 // 16-byte Folded Spill
        add     x29, sp, #16    //将sp+16存储于x29中
        bl      FuncA()        //跳转到 FuncA()
        stur    w0, [x29, #-4] //将w0寄存器中的值读到 x29-4处
        mov     w0, wzr
        ldp     x29, x30, [sp, #16]  // 16-byte Folded Reload
        add     sp, sp, #32     //归还 main函数栈空间
        ret

以下是main函数和FuncA的栈空间示意图，"mem align"是为内存对齐留空。

函数入参及传递返回值过程

以一个有10个参数的函数funcA为例：

前8个参数(1、2、4、8、16、32、64、128)按顺序使用w0-w7寄存器来入参，而p9 p10这两个参数是直接保存在main的栈空间上，接下来看下funcA是怎么使用这两个参数的：

funcA在越过自己的栈空间，把位于main函数栈空间上的p9和p10复制到自己的栈空间上，然后在后续流程中使用（据我测试，GCC编译器会省掉这个复制过程，直接越过自己的栈空间取值到寄存器做加法）。同时可以看到这里w0被用来传递返回值。

入参顺序

在上一个例子里，如果把入参部分改为：

在clang编译后入参部分就会变成：

FuncA中实际入参p1~p10的值是1~10，p1 + p2 + p3 = 3，p9 + p10 = 19

而在GCC编译器下，会先运算所有++，再逐个入参，也就是例子中所有实际入参的参数都是10，相应的执行结果也会变成p1 + p2 + p3 = 30，p9 + p10 = 20；如果把参数都改成d++，clang入参是0~9，GCC则是9~0；

关于编译器间的微妙差异，各位可到https://godbolt.org/自行深入探索。

变参函数

printf是最常用的变参函数，变参函数的入参过程和普通函数类似，优先使用x0-x7寄存器，超出部分保存在父函数的栈上。

变参函数一定会将x0-x7的值入栈，第九个及其他参数则会越过自身栈空间去父函数的栈上读取。变参函数需要严格检查入参个数，对于printf，它是通过format字符串来确认入参个数的。这也是为什么当printf中漏掉参数时会输出无效值，它可能是寄存器上的值，也可能是栈空间上的某个值，取决于它具体是第几个参数。

下面是一个自定义变参函数示例：

#include <iostream>
#include <cstdarg>
using namespace std;

int sum(int count, ...) {
 
    va_list ap;
    va_start(ap, count);
 
    int res = 0;
    for (int i = 0; i < count; i++) {
        res += va_arg(ap, int); // 需指定类型
    }
    va_end(ap);

    return res;
}

int main(void)
{
    sum(30,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30);
}

虚函数表

当一个类或者其基类的定义中存在虚函数时，这个类的实例的内存起始位置会保存一个指针指向类域的虚函数表（即，这个类的所有对象共用同一张虚函数表）。虚函数表的数据结构类似一个数组，按函数的声明顺序保存了所有虚函数的函数起始地址。

虚函数表存储在ELF的只读数据段（.rodata）、虚函数存储在代码段（.text）。

典型问题分析过程

以空指针解引用问题为例。

Crash BackTrace

从 crash 信息可以初步看出问题类型是null pointer dereference，这种问题一般借助addr2line至少可以找到是哪个空指针被解引用。用 addr2line 去解析问题 daily 包的 symbol 库（在vendor组件中下载），可以初步看下挂在哪里。

Addr2line

# 代码根目录下
./prebuilts/clang/host/linux-x86/clang-r450784e/bin/llvm-addr2line -Cipfe com.qti.stats.aec.so 000000000004fefc

addr2line的解析结果会显示目标地址对应的代码文件和行号，000000000004fefc这个crash地址对应的位置如上图，这一行有三处显性的指针解引用：两处对pAECAlgo，一处对pAlgo。

但从代码逻辑上看，能够走到这里就足以证明这两个指针都不为空。可以用objdump反汇编symbol库，进一步定位crash的地方究竟是解引用了哪个空指针。

objdump

# objdump结果输出到res.txt供后续查看
./prebuilts/clang/host/linux-x86/clang-r450784e/bin/llvm-objdump -d com.qti.stats.aec.so > res.txt

更多objdump命令参数：objdump命令解析-CSDN博客

4fefc附近反汇编片段截取如下：

pAECAlgo的类型是AECAlgorithm_Internal*，这个指针被解引用两次：其中一次是pAECAlgo->cameraId做函数入参，从结构体定义可以确认pAECAlgo->cameraId的地址偏移是68，在上面的汇编片段里只有4fef4这一行存在68这个偏移，其功能是从x19+68取值保存在w1寄存器中，而在w1未被覆盖的情况下程序就在4ff00进行了跳转，所以4fef4这一行有可能是一个入参操作。有足够的证据表明，此处x19保存的应该就是pAECAlgo。继续向上追溯的话，可以发现这里的x19来自函数入参，与代码也能对应上。

再看4fef0这一行，这里从x19+40读取内存到x0，从结构体定义可以确定pAECAlgo->pAlgo的地址偏移是40，而它保存在x0寄存器可能是调用类函数时的隐藏入参this指针。因此此处x0保存的就是pAECAlgo->pAlgo。

4fef8行从x0直接无偏移取值到x8，通过查找pAECAlgo->pAlgo的类型定义可以确定pAECAlgo->pAlgo指向的实例，其所属的类中存在虚函数，因此这行取值一定会取到类域的虚函数表指针。即x8保存了虚函数表指针。

下一行4fefc在虚函数表指针上加偏移40读取内存到x9，结合代码可以推断这可能是setCameraId的虚函数地址，通过查定义setCameraId的确是一个虚函数，符合推断。

下一行程序跳转到x9所指位置，是一个函数跳转动作，程序将跳转到setCameraId中执行。

AECAlgorithm_Internal* pAECAlgo = reinterpret_cast<AECAlgorithm_Internal*>(pAECAlgorithm);
// crash line
pAECAlgo->pAlgo->setCameraId(pAECAlgo->cameraId);

// struct defines
typedef struct /** @cond */ CHIAECAlgorithm /** @endcond */
{
    CDKResult (*AECProcess)(CHIAECAlgorithm* pCHIAECAlgorithm, const AECAlgoInputList* pInput, AECAlgoOutputList* pOutput);
    CDKResult (*AECGetParam)(CHIAECAlgorithm* pCHIAECAlgorithm, AECAlgoGetParam* pGetParam);
    CDKResult (*AECSetParam)(CHIAECAlgorithm* pCHIAECAlgorithm, const AECAlgoSetParamList* pSetParam);
    CDKResult (*AECGetFeatureCapability)(CHIAECAlgorithm* pCHIAECAlgorithm, UINT64* pFeatures);
    VOID      (*AECDestroy)(CHIAECAlgorithm* pCHIAECAlgorithm, const AECAlgoDestroyParamList* pDestroyParams);
} CHIAECAlgorithm;

struct AECAlgorithm_Internal : public CHIAECAlgorithm
{
    IAECXControl* pAlgo;
    VOID*         pLogs;
    BOOL          bDepthAECEnable;
    BOOL          bIsWarmStartDone;
    UINT          instanceCount;
    UINT          cameraId;
};

问题JIRA中贴的分析：

pAlgo是指向CAECXControl实例的指针，这个类继承于基类IAECXControl，整个解引用过程如下：

从tombStone中可以看到pAlgo（保存在x0寄存器）指向的内存，也就是IAECXControl实例所在位置附近的情况：

拓展

为什么SetCameraId函数地址偏移是+40(0x28)

单从.h文件里的声明来看，SetCameraId是第五个虚函数，在虚函数表中的偏移应该是 4 * 8 = 32

这个问题涉及到deleting destructor，由于这个类涉及继承，子类的虚函数表+0位置的是普通析构 complete object destructor，但在+8位置还有一个 deleting destructor。

在这里插入实验代码段，编译后再反汇编查看结果，可以看到直接调用析构时调用了虚函数表+0位置的析构，使用delete operator时调用了虚函数表+8位置的deleting析构。

为什么需要deleting destructor

delete行为分为析构和内存释放（operator delete），正确的析构行为可以通过调用虚析构函数实现，而内存释放时不止需要知道对象的地址，还需要知道实例的实际大小（有时子类和基类实例的内存占用大小不一样）。deleting destructor可以理解为delete的一个virtual封装，里面既调用了析构函数，也调用了operator delete去释放正确的内存。

举例说明（ARM64 GCC）：