常见的Native Crash类型

类型	子类	原因
SIGSEGV	SEGV_MAPERR	地址不在 /proc/self/maps 映射中
	SEGV_ACCERR	没有访问权限
	SEGV_MTESERR	MTE特有类型
SIGABRT		程序主动退出，常见调用函数abort()，raise()等
SIGILL	ILL_ILLOPC	非法操作码（opcode）
	ILL_ILLOPN	非法操作数（operand）
	ILL_ILLADR	非法寻址
	ILL_ILLTRP	非法trap，如_builtintrap()主动崩溃
	ILL_PRVOPC	非法特权操作码(privileged opcode)
	ILL_PRVREG	非法特权寄存器(privileged register)
	ILL_COPROC	协处理器错误
	ILL_BADSTK	内部堆栈错误
SIGBUS	BUS_ADRALN	访问地址未对齐
	BUS_ADRERR	访问不存在的物理地址，常见访问的文件截断
	BUS_OBJERR	特定对象的硬件错误
SIGFPE	FPE_INTDIV	整数除以0
	FPE_INTOVF	整数溢出
	FPE_FLTDIV	浮点数除以0
	FPE_FLTOVF	浮点数上溢（overflow）
	FPE_FLTUND	浮点数下溢（underflow）
	FPE_FLTRES	浮点数结果不精确
	FPE_FLTINV	无效的浮点运算
	FPE_FLTSUB	越界

Android日志

当程序发生了 Native Crash 错误，Android 的日志会输出到 log crash buffer 上，因此我们通过adb logcat -b crash 抓取到相应的错误报告，而日志本身能提供的信息是有限的，仅仅是错误堆栈，与当前线程的寄存器信息。

yaml复制代码--------- beginning of crash
06-07 01:53:32.465 12027 12027 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
06-07 01:53:32.465 12027 12027 F DEBUG : Revision: '0'
06-07 01:53:32.466 12027 12027 F DEBUG : ABI: 'arm64'
06-07 01:53:32.466 12027 12027 F DEBUG : Timestamp: 2022-06-07 01:53:32.033409857+0800
06-07 01:53:32.466 12027 12027 F DEBUG : Process uptime: 0s
06-07 01:53:32.466 12027 12027 F DEBUG : Cmdline: mediaserver64
06-07 01:53:32.466 12027 12027 F DEBUG : pid: 1139, tid: 11981, name: NPDecoder >>> mediaserver64 <<<
06-07 01:53:32.466 12027 12027 F DEBUG : uid: 1013
06-07 01:53:32.466 12027 12027 F DEBUG : tagged_addr_ctrl: 0000000000000001
06-07 01:53:32.466 12027 12027 F DEBUG : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7c02d886f0
06-07 01:53:32.466 12027 12027 F DEBUG : x0 79748c5e568e2ddc x1 0000007ca13c3618 x2 0000000000000000 x3 0000007ca1291000
06-07 01:53:32.466 12027 12027 F DEBUG : x4 0000000001909705 x5 0000000000000000 x6 0000007c02d88808 x7 b60625655bf0252f
06-07 01:53:32.467 12027 12027 F DEBUG : x8 0000000000000080 x9 0000007ca126fed7 x10 0000000000000006 x11 0000007bfd0a81fc
06-07 01:53:32.467 12027 12027 F DEBUG : x12 9ef8a95ca9649dbe x13 e44782d5ac38720e x14 0000007bfd0a8030 x15 0000001e56307b5c
06-07 01:53:32.467 12027 12027 F DEBUG : x16 0000007c95dfdb70 x17 0000007c9844f118 x18 0000007bfaa28000 x19 b400007c13c246d0
06-07 01:53:32.467 12027 12027 F DEBUG : x20 0000007c02d88730 x21 b400007c13c67c00 x22 0000000000000415 x23 0000007c02d89000
06-07 01:53:32.467 12027 12027 F DEBUG : x24 0000000000000002 x25 b400007c13c246d0 x26 b400007c13c67c00 x27 0000007c02d89000
06-07 01:53:32.467 12027 12027 F DEBUG : x28 0000007ca13c2c28 x29 0000007c02d886f0
06-07 01:53:32.467 12027 12027 F DEBUG : lr 0000007c02d886f0 sp 0000007c02d886d0 pc 0000007c02d886f0 pst 0000000080001000
06-07 01:53:32.467 12027 12027 F DEBUG : backtrace:
06-07 01:53:32.467 12027 12027 F DEBUG : #00 pc 00000000000f86f0 [anon:stack_and_tls:11981]

当只有日志堆栈不能进行更详细的分析时，我们还需要程序的部分内存信息以及寄存器信息，而Android 的错误机制会相应的会生成一份 tombstone 文件保存到 /data/tombstones/tombstone_xx ，对于没有 Root 权限的机器则可以通过 adb bugreport 抓取出 tombstone 文件。

Tombstone

tombstone 文件保存的信息有错误程序的体系结构，通俗的说 arm、arm64 等，发生时间点，程序名，错误类型，错误程序的进程号、线程号，错误现场寄存器，堆栈和部分寄存器地址附近的内存信息，程序内存映射表 /proc/self/maps ，FD 信息以及发生错误时该程序输出的日志。

yaml复制代码ABI: 'arm64' 【 arm64的程序 】
Timestamp: 2022-06-07 01:53:32.033409857+0800 【 发生错误的时间戳 】
Process uptime: 0s
Cmdline: mediaserver64 【 程序名 】
pid: 1139, tid: 11981, name: NPDecoder >>> mediaserver64 <<< 【 进程号、线程号 】
uid: 1013

错误类型

ini复制代码signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7c02d886f0
【 错误类型是 SIGSEGV，子类是 SEGV_ACCERR，错误地址0x7c02d886f0 】
SIGSEGV 也是我们最常见的 Native Crash 类型，大部分时候我们称其为段错误，
而错误意思是在 PC=0x7c02d886f0 上发生拒绝访问的段错误。

寄存器信息

复制代码x0 79748c5e568e2ddc x1 0000007ca13c3618 x2 0000000000000000 x3 0000007ca1291000
x4 0000000001909705 x5 0000000000000000 x6 0000007c02d88808 x7 b60625655bf0252f
x8 0000000000000080 x9 0000007ca126fed7 x10 0000000000000006 x11 0000007bfd0a81fc
x12 9ef8a95ca9649dbe x13 e44782d5ac38720e x14 0000007bfd0a8030 x15 0000001e56307b5c
x16 0000007c95dfdb70 x17 0000007c9844f118 x18 0000007bfaa28000 x19 b400007c13c246d0
x20 0000007c02d88730 x21 b400007c13c67c00 x22 0000000000000415 x23 0000007c02d89000
x24 0000000000000002 x25 b400007c13c246d0 x26 b400007c13c67c00 x27 0000007c02d89000
x28 0000007ca13c2c28 x29 0000007c02d886f0
lr 0000007c02d886f0 sp 0000007c02d886d0 pc 0000007c02d886f0 pst 0000000080001000

堆栈信息

makefile复制代码backtrace:
#00 pc 00000000000f86f0 [anon:stack_and_tls:11981] 【PC刚好落在线程栈地址上】
这种情况很少见，虽然它只有的一条堆栈，并不代表程序是从这里开始运行，出现的这种情况仅仅 unwind 无法正确的回溯。
我们是可以通过栈地址空间内存进行恢复调用栈，用户态主线程栈（红色部分）结构如下：

UML diagram.jpg

1
2
3

ruby复制代码而线程栈位于 mmap segmemt上，我们可以在 /proc/self/maps 上找到该线程栈的地址空间范围。
0000007c'02c90000-0000007c'02d8bfff rw- 0 fc000 [anon:stack_and_tls:11981]
大多数 arm64 的 Linux Android 程序，它的线程调用栈结构样例如下：

UML diagram (12).jpg

内存信息

tombstone 会记录当前有效地址的寄存器附近内存信息，大小为0x100，这个可以修改文件
system/core/debuggerd/libdebuggerd/utility.cpp 中的宏定义 MEMORY_BYTES_TO_DUMP 参数
像这种一条堆栈的情况下，栈的内存信息配合下边的映射表可以帮助到我们对栈进行恢复。

erlang复制代码memory near x1 (/system/lib64/libstagefright.so):
0000007ca13c35f0 0000000000000000 0000000000000000 ................
0000007ca13c3600 0000000000000000 0000000000000000 ................
0000007ca13c3610 0000000000000000 0000007ca132326c ........l22.|...
0000007ca13c3620 0000007ca1324008 0000007ca10552e4 .@2.|....R..|...
0000007ca13c3630 0000007ca10552e8 0000007ca10552ec .R..|....R..|...
0000007ca13c3640 0000007ca10552f4 0000007ca132402c .R..|...,@2.|...
0000007ca13c3650 0000000000000000 0000000000000000 ................
0000007ca13c3660 0000000000000000 0000000000000000 ................
0000007ca13c3670 0000000000000000 0000007ca134ea84 ..........4.|...
0000007ca13c3680 0000007ca134ecec 0000007ca10552e4 ..4.|....R..|...
0000007ca13c3690 0000007ca10552e8 0000007ca10552ec .R..|....R..|...
0000007ca13c36a0 0000007ca10552f4 0000007ca134ed10 .R..|.....4.|...
0000007ca13c36b0 0000000000000000 0000000000000000 ................
0000007ca13c36c0 0000000000000000 0000000000000000 ................
0000007ca13c36d0 0000000000000000 0000007ca135d02c ........,.5.|...
0000007ca13c36e0 0000007ca135d4b8 0000007ca10552e4 ..5.|....R..|...

memory near x29 ([anon:stack_and_tls:11981]):
0000007c02d886d0 b400007c13c246d0 0000000001909705 .F..|……….. 【SP = 0x0000007c02d886d0】
0000007c02d886e0 0000007c02d88700 6f2ab3b40fa2f8ef ….|………*o*
0000007c02d886f0 0000007c02d88750 0000007ca133f8e0 P…|…..3.|…*【x29 = 0x0000007c02d886f0】
0000007c02d88700 0000000000000002 0000000000000000 …………….*
0000007c02d88710 0000000000000415 0000000001909705 …………….*
0000007c02d88720 0000000000000000 0000007c02d88808 …………|…*
0000007c02d88730 b400007c13c67c00 0000000000000000 .|..|………..*
0000007c02d88740 0000007c02d89000 6f2ab3b40fa2f8ef ….|………*o
0000007c02d88750 0000007c02d88830 0000007ca796ee7c 0…|…|…|…
0000007c02d88760 0000007ca79f3dd8 0000007ca79edb80 .=..|…….|…
0000007c02d88770 0000007c02d89000 b400007c13c04680 ….|….F..|…
0000007c02d88780 0000000000000000 0000000000000002 …………….
0000007c02d88790 b400007c13c67c00 0000000000000000 .|..|………..
0000007c02d887a0 0000000000000000 b400007c13c7c100 …………|…
0000007c02d887b0 0000007c02d88830 0000007ca796d420 0…|… …|…
0000007c02d887c0 0000007c02d88830 0000007ca796d460 0…|…`…|…

memory near lr ([anon:stack_and_tls:11981]):
0000007c02d886d0 b400007c13c246d0 0000000001909705 .F..|………..
0000007c02d886e0 0000007c02d88700 6f2ab3b40fa2f8ef ….|………*o*
0000007c02d886f0 0000007c02d88750 0000007ca133f8e0 P…|…..3.|…*
0000007c02d88700 0000000000000002 0000000000000000 …………….*
0000007c02d88710 0000000000000415 0000000001909705 …………….*
0000007c02d88720 0000000000000000 0000007c02d88808 …………|…*
0000007c02d88730 b400007c13c67c00 0000000000000000 .|..|………..*
0000007c02d88740 0000007c02d89000 6f2ab3b40fa2f8ef ….|………*o
0000007c02d88750 0000007c02d88830 0000007ca796ee7c 0…|…|…|…
0000007c02d88760 0000007ca79f3dd8 0000007ca79edb80 .=..|…….|…
0000007c02d88770 0000007c02d89000 b400007c13c04680 ….|….F..|…
0000007c02d88780 0000000000000000 0000000000000002 …………….
0000007c02d88790 b400007c13c67c00 0000000000000000 .|..|………..
0000007c02d887a0 0000000000000000 b400007c13c7c100 …………|…
0000007c02d887b0 0000007c02d88830 0000007ca796d420 0…|… …|…
0000007c02d887c0 0000007c02d88830 0000007ca796d460 0…|…`…|…

memory near sp ([anon:stack_and_tls:11981]):
0000007c02d886b0 0000000000000018 0000007caae98c58 ……..X…|…
0000007c02d886c0 0000007c02d886f0 0000007c95de6754 ….|…Tg..|…
0000007c02d886d0 b400007c13c246d0 0000000001909705 .F..|………..
0000007c02d886e0 0000007c02d88700 6f2ab3b40fa2f8ef ….|………*o*
0000007c02d886f0 0000007c02d88750 0000007ca133f8e0 P…|…..3.|…*
0000007c02d88700 0000000000000002 0000000000000000 …………….*
0000007c02d88710 0000000000000415 0000000001909705 …………….*
0000007c02d88720 0000000000000000 0000007c02d88808 …………|…*
0000007c02d88730 b400007c13c67c00 0000000000000000 .|..|………..*
0000007c02d88740 0000007c02d89000 6f2ab3b40fa2f8ef ….|………*o
0000007c02d88750 0000007c02d88830 0000007ca796ee7c 0…|…|…|…
0000007c02d88760 0000007ca79f3dd8 0000007ca79edb80 .=..|…….|…
0000007c02d88770 0000007c02d89000 b400007c13c04680 ….|….F..|…
0000007c02d88780 0000000000000000 0000000000000002 …………….
0000007c02d88790 b400007c13c67c00 0000000000000000 .|..|………..
0000007c02d887a0 0000000000000000 b400007c13c7c100 …………|…

memory near pc ([anon:stack_and_tls:11981]):
0000007c02d886d0 b400007c13c246d0 0000000001909705 .F..|………..
0000007c02d886e0 0000007c02d88700 6f2ab3b40fa2f8ef ….|………*o*
0000007c02d886f0 0000007c02d88750 0000007ca133f8e0 P…|…..3.|…*
0000007c02d88700 0000000000000002 0000000000000000 …………….*
0000007c02d88710 0000000000000415 0000000001909705 …………….*
0000007c02d88720 0000000000000000 0000007c02d88808 …………|…*
0000007c02d88730 b400007c13c67c00 0000000000000000 .|..|………..*
0000007c02d88740 0000007c02d89000 6f2ab3b40fa2f8ef ….|………*o
0000007c02d88750 0000007c02d88830 0000007ca796ee7c 0…|…|…|…
0000007c02d88760 0000007ca79f3dd8 0000007ca79edb80 .=..|…….|…
0000007c02d88770 0000007c02d89000 b400007c13c04680 ….|….F..|…
0000007c02d88780 0000000000000000 0000000000000002 …………….
0000007c02d88790 b400007c13c67c00 0000000000000000 .|..|………..
0000007c02d887a0 0000000000000000 b400007c13c7c100 …………|…
0000007c02d887b0 0000007c02d88830 0000007ca796d420 0…|… …|…
0000007c02d887c0 0000007c02d88830 0000007ca796d460 0…|…`…|…

内存映射表

bash复制代码memory map (1146 entries):
0000005f'fabc7000-0000005f'fabc7fff r-- 0 1000 /system/bin/mediaserver64
0000005f'fabc8000-0000005f'fabc9fff r-x 1000 2000 /system/bin/mediaserver64
0000005f'fabca000-0000005f'fabcafff r-- 3000 1000 /system/bin/mediaserver64
0000007b'e79a3000-0000007b'e7d93fff --- 0 3f1000

0000007c'a120e000-0000007c'a128efff r-- 0 81000 /system/lib64/libstagefright.so
0000007c'a128f000-0000007c'a13c0fff r-x 81000 132000 /system/lib64/libstagefright.so
0000007c'a13c1000-0000007c'a13cffff r-- 1b3000 f000 /system/lib64/libstagefright.so
0000007c'a13d0000-0000007c'a13d1fff rw- 1c1000 2000 /system/lib64/libstagefright.so

0000007c'a787c000-0000007c'a78f4fff r-- 0 79000 /system/lib64/libmediaplayerservice.so
0000007c'a78f5000-0000007c'a79ecfff r-x 79000 f8000 /system/lib64/libmediaplayerservice.so
0000007c'a79ed000-0000007c'a79f8fff r-- 171000 c000 /system/lib64/libmediaplayerservice.so
0000007c'a79f9000-0000007c'a79f9fff rw- 17c000 1000 /system/lib64/libmediaplayerservice.so

FD信息

javascript复制代码open files:
fd 0: /dev/null (unowned)
fd 1: /dev/null (unowned)
fd 2: /dev/null (unowned)
fd 3: socket:[62562] (unowned)
fd 4: /dev/binderfs/binder (unowned)
fd 5: /dev/binderfs/hwbinder (unowned)
fd 6: /sys/kernel/tracing/trace_marker (unowned)
fd 7: /dev/ashmem4945d9b6-db30-413c-88c5-e50674f154c7 (unowned)
fd 8: /dmabuf: (unowned)
fd 9: /dev/ashmem4945d9b6-db30-413c-88c5-e50674f154c7 (unowned)
fd 10: /storage/emulated/0/zapya/folder/华语音乐/IN-K&王忻辰&苏星婕 - 落日与晚风.mp3 (owned by unique_fd 0x7c13c7a498)
fd 11: /dev/ashmem4945d9b6-db30-413c-88c5-e50674f154c7 (unowned)
...

Coredump

前面 tombstone 文件内容，可以了解到它的信息很有限，当我们需要更多的内存信息时，它无法满足我们，这时 coredump 就尤为重要了，它可以按我们配置抓取相应的内存信息，关于 core 的介绍，见：
man7.org/linux/man-p…

AOSP方法

bash复制代码# build/envsetup.sh
# coredump_setup - enable core dumps globally for any process
#                  that has the core-file-size limit set correctly
#
# NOTE: You must call also coredump_enable for a specific process
#       if its core-file-size limit is not set already.
# NOTE: Core dumps are written to ramdisk; they will not survive a reboot!

function coredump_setup()
{
    echo "Getting root...";
    adb root;
    adb wait-for-device;

    echo "Remounting root partition read-write...";
    adb shell mount -w -o remount -t rootfs rootfs;
    sleep 1;
    adb wait-for-device;
    adb shell mkdir -p /cores;
    adb shell mount -t tmpfs tmpfs /cores;
    adb shell chmod 0777 /cores;

    echo "Granting SELinux permission to dump in /cores...";
    adb shell restorecon -R /cores;

    echo "Set core pattern.";
    adb shell 'echo /cores/core.%p > /proc/sys/kernel/core_pattern';

    echo "Done."
}

# coredump_enable - enable core dumps for the specified process
# $1 = PID of process (e.g., $(pid mediaserver))
#
# NOTE: coredump_setup must have been called as well for a core
#       dump to actually be generated.

function coredump_enable()
{
    local PID=$1;
    if [ -z "$PID" ]; then
        printf "Expecting a PID!\n";
        return;
    fi;
    echo "Setting core limit for $PID to infinite...";
    adb shell /system/bin/ulimit -P $PID -c unlimited
}

常用方法

给 system_server 配置 coredump 参数，由于目标进程的 coredump 生成的目录受 selinux 权限限制，因此这种方法配置抓 coredump 的方法要注意目标进程对哪些目录文件有读写的 selinux 权限，再配置相应的目录。

bash复制代码adb wait-for-device
adb root
adb shell mkdir /data/cores
adb shell chmod 777 /data/cores
#adb shell setenforce 0
adb shell restorecon -R /data/cores
adb shell 'echo /data/cores/core.%e.%p > /proc/sys/kernel/core_pattern'
adb shell 'system/bin/ulimit -P `pidof system_server` -c unlimited'
#adb shell 'echo 2 > /proc/sys/fs/suid_dumpable'

注意：确定问题与selinux权限无关，可以通过adb shell setenforce 0关闭selinux权限

给 com.android.settings 配置抓取 coredump 的参数，由于前面的配置中 /data/cores 目录恢复 selinux 权限后如下：

drwxrwxrwx 2 root root u:object_r:system_data_file:s0 3452 2022-07-04 15:08 cores

我们知道 app 一定有权限对自身的 /data/data/$PACKAGE/ 目录下的文件具有读写权限，于是可以配置成如下参数：

kotlin复制代码adb wait-for-device
adb root
adb shell mkdir /data/data/com.android.settings/cores
adb shell chmod 777 /data/data/com.android.settings/cores
adb shell restorecon -R /data/data/com.android.settings/cores
adb shell 'echo /data/data/com.android.settings/cores/core.%e.%p > /proc/sys/kernel/core_pattern'
adb shell 'system/bin/ulimit -P `pidof com.android.settings` -c unlimited'
#adb shell 'echo 2 > /proc/sys/fs/suid_dumpable'

1
2
3

shell复制代码当我们在机器上验证对这个app进行kill -11模拟时
$ kill -11 `pidof com.android.settings`
$ ls /data/data/com.android.settings/cores/core.ndroid.settings.27946

参数说明

coredump_filter 进程默认值是0x23，只抓取：私有匿名/共享匿名/私有大尺寸页，需要抓全部内存信息则 adb shell ‘echo 0x27 > /proc/$PID/coredump_filter’ 即可。

节点	参数
/proc/$PID/coredump_filter	bit0: 私有匿名
	bit1: 共享匿名
	bit2: 有底层文件的私有映射
	bit3: 有底层文件共享映射
	bit4: ELF头
	bit5: 私有大尺寸页
	bit6: 共享大尺寸页

core_pattern 控制生成 core 的文件名，以及输出的 core 的位置。例如：

adb shell ‘echo /data/cores/core.%p > /proc/sys/kernel/core_pattern’

节点	参数
/proc/sys/kernel/core_pattern	%p: 添加pid
	%u: 添加当前uid
	%g: 添加当前gid
	%s: 添加导致产生core的信号
	%t: 添加core文件生成时的unix时间
	%h: 添加主机名
	%e: 添加命令名
	％E: 可执行文件的路径名，用斜杠（’/’）替换为感叹号（’！’）。

当程序调用了 seteuid()/setegid() 改变进程的有效用户或组，则在默认情况下系统不会为这些进程生成 core，此时你可能需要调整 suid_dumpable 参数进入调试模式或安全模式下进行。

节点	参数
/proc/sys/fs/suid_dumpable	0：默认模式
	1：调试模式
	2：安全模式

文件格式

core 文件也是ELF文件的一种，因此它的主体格式组成部分与 ELF 文件相同，以案例讲解的 core 文件为例，它主要组成部分为 /proc/self/maps 下的VMA以及各个线程寄存器。其中寄存器信息存放在PT_NOTE，各VMA存放在 PT_LOAD，当被过滤掉的 VMA，它只有 Program Header 描述，没有对应的 segment，也就是对应的段的 p_filesz = 0x0。

UML diagram (16).jpg

UML diagram (5).jpg

离线调试

注：MTK 平台的 MINIDUMP 也是 coredump 的一种，它所保存的内存信息有限，core 的分析可以使用 GDB、lldb 等调试工具，如何使用这些调试工具，这里就不一一介绍。

bash复制代码$ ~/work/debug/gdb_arm64/gdb-12.1/output/bin/aarch64-linux-gdb
当我们没有符号表时，仅加载 core-file 也是可以使用的。
(gdb) core-file PROCESS_MINIDUMP
当我们有相应的符号表时，即可加载符号表目录
(gdb) set solib-search-path symbols/
或者
(gdb) set sysroot symbols/

命令	用途
(gdb) info sharedlibrary	显示所有共享库的地址范围
(gdb) info registers	显示当前线程的当前帧寄存器信息
(gdb) info locals	显示当前帧的局部变量
(gdb) info thread	显示有哪些线程
(gdb) thread 2	切换到2号线程上
(gdb) bt	显示当前线程的堆栈
(gdb) thread apply all [command]例如打印所有线程堆栈(gdb) thread apply all bt	让所有线程做同样的命令
(gdb) frame	显示当前帧信息
(gdb) frame 3	切换到#3帧
(gdb) print 或 (gdb) p	打印变量
(gdb) ptype ‘android::AHandler’	查看某个class或struct的数据结构
(gdb) ptype /o ‘android::AHandler’	查看数据类型占多少字节
(gdb) set print pretty on	格式化输出
(gdb) set log on	保存gdb输出的结果
(gdb) x /gx 0x7c02d886f0	读取地址0x7c02d886f0内存内容，其中输出格式如下：o(octal), x(hex), d(decimal),u(unsigned decimal), t(binary),f(float), a(address), i(instruction),c(char), s(string),z(hex, zero padded on the left).
(gdb) disassemble 0x0000007c95de6708或(gdb) disassemble ‘android::AMessage::setTarget’	显示函数汇编信息

内存检测机制

ASAN

在 Android 11 之后的 AOSP master 中，弃用了 arm64 上的平台开发 ASAN，改为使用 HWASAN，AddressSanitizer (ASAN) 是一种基于编译器的快速检测工具，用于检测内存错误。

类型	意义
Stack and heap buffer overflow/underflow	堆栈和堆缓冲区上溢/下溢
Heap use after free	使用已释放的内存
Stack use outside scope	超出栈范围
Double free/wild free	多次释放内存/错误释放

HWASAN

HWASan 仅适用于 Android 10 及更高版本，且只能用于 AArch64 硬件，具备 ASAN 同样的检测能力，在 Linux-4.14 版本以上支持 tagged-pointers才能使用。

makefile复制代码编译Android版本时带入环境变量如下：
$ export SANITIZE_TARGET=hwaddress
跳过某个模块，在相应模块下的Android.bp文件下添加内容如下：
sanitize: {
hwaddress: false,
address: false,
},

Android.mk则添加内容如下：
LOCAL_NOSANITIZE := hwaddress

APP构建支持HWASAN则在Application.mk下添加内容如下：
APP_STL := c++_shared
APP_CFLAGS := -fsanitize=hwaddress -fno-omit-frame-pointer
APP_LDFLAGS := -fsanitize=hwaddress

MTE

最新 Android S 上引入的 ARM Memory Tagging Extension (MTE)，MTE 的原理和 HWASan 类似，最大的区别在于 HWASan 需要重新编译，在所有内存访问前插桩相应的检测函数来实现，而 MTE 则在读写指令内部完成检测，完全由硬件支持。
更多内容转至掘金大佬-芦半山：

juejin.cn/post/684490…

juejin.cn/post/701359…

野指针的危害

当所指向的对象被释放或者收回，但是对该指针没有作任何的修改，以至于该指针仍旧指向已经回收的内存地址，此情况下该指针便称 Wild pointer (野指针)，如果这个野指针所指向的内存被分配给其它指针，而这个野指针仍在使用，程序将难以预测。

arduino复制代码#include <stdio.h>
class A {
public:
    virtual ~A() = default;
    virtual void foo() {
        printf("A:%ld\n", a);
    }

    long a;
};

class B {
public:
    virtual ~B() = default;
    virtual void foo() {
        printf("B:%ld\n", b);
    }

    long b;
};

int main(int /*argc*/, char** /*argv[]*/) {
    A *a = new A();
    A *a_bak = a;
    a->a = 1000L;
    printf("A ptr = %p\n", a);
    delete a; // 此时a指针已经被free掉，那么指针a_bak是个野指针
    B *b = new B();
    printf("B ptr = %p\n", b);
    b->b = 2000L;
    b->foo();
    a_bak->foo(); // 此处程序会运行怎么结果
    delete b;
    return 0;
}

以上程序会怎么输出，由于 B 与 A 的数据结构大小一致，运行在同一个线程，极大可能会分配刚释放的指针地址，因此这个程序最后指针 b 与指针 a_bak 是同一个。

ini复制代码# ./data/Tester64
A ptr = 0xb400007690205010
B ptr = 0xb400007690205010
B:2000
B:2000

像以上这个结果，那程序如下改写，那么可怕的事情就会出现，下面这个程序会报什么错。

arduino复制代码#include <stdio.h>
class A {
public:
    long bad;
    long a;
};

class B {
    public:
    virtual ~B() = default;
    virtual void foo() {
        b = 2000L;
        printf("B:%ld\n", b);
    }

    long b;
};

int main(int /*argc*/, char** /*argv[]*/) {
    A *a = new A();
    A *a_bak = a;
    printf("A ptr = %p\n", a);
    delete a;
    B *b = new B();
    printf("B ptr = %p\n", b);
    a_bak->bad = 0x20L;
    b->foo();
    delete b;
    return 0;
}

上面这个程序在27行处，bad 会将 B 的虚函数表破坏，导致28和29行在虚函数表上寻找 foo 函数与析构函数地址时发段错误。

yaml复制代码Timestamp: 2022-07-06 14:47:50.925654058+0800
Process uptime: 0s
Cmdline: ./data/Tester64
pid: 12652, tid: 12652, name: Tester64 >>> ./data/Tester64 <<<
uid: 0
tagged_addr_ctrl: 0000000000000001
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x28
Cause: null pointer dereference
x0 b40000762f005010 x1 b40000762f01b000 x2 0000000000000007 x3 ffffffffffffffff
x4 ffffffffffffffff x5 0000000040100401 x6 b40000762f01b006 x7 3637303030303462
x8 0000000000000020 x9 a454ef76eb4317d3 x10 0000000000004001 x11 0000000000000000
x12 0000000000000000 x13 0000000000000002 x14 0000000000000010 x15 0000000000000010
x16 000000762f5a0c58 x17 000000762f5910d4 x18 000000763745c000 x19 b40000762f005010
x20 b40000762f005010 x21 0000007fe173d378 x22 0000000000000001 x23 0000000000000000
x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000
x28 0000000000000000 x29 0000007fe173d2e0
lr 0000005ac14600c8 sp 0000007fe173d2e0 pc 0000005ac14600d0 pst 0000000060001000

backtrace:
#00 pc 00000000000010d0 /data/Tester64 (main+124)
#01 pc 000000000008436c /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+100)

程序会出错还好，如果程序不会出错，仍继续运行，那么这个程序将变得很可怕，因为你不知道程序将会怎么运行，像下面这个程序，刻意改写控制程序往其它方向运行。

arduino复制代码#include <stdio.h>
class A {
public:
    void *bad;
    long a;
};

class B {
public:
    virtual ~B() {
        printf("delete B\n");
    }
    
    virtual void foo() {
        b = 2000L;
        printf("B:%ld\n", b);
    }

    long b;
};

void func1() {
    printf("Hello !!\n");
}

void func2() {
    printf("GoGoGo !!\n");
}

int main(int /*argc*/, char** /*argv[]*/) {
    A *a = new A();
    A *a_bak = a;
    printf("A ptr = %p\n", a);
    delete a;
    B *b = new B();
    printf("B ptr = %p\n", b);
    
    long *data = new long[4] {0x0L, (long)func2, (long)func1, 0x0L};
    a_bak->bad = data;
    
    printf("Test .. \n");
    b->foo();
    delete b;
    printf("Done.\n");
    return 0;
}

ini复制代码# ./data/Tester64
A ptr = 0xb400007ce9605010
B ptr = 0xb400007ce9605010
Test ..
Hello !!
GoGoGo !!
Done.

数组越界的危害

比起前面的野指针，数组越界大多数情况都能被 HWASAN 等内存检测发现，当然前面的野指针情况也是能被检测发现的，数组越界往往会出现某个对象的内存前半部分被污染，而后半部分数据正常的情况。

arduino复制代码#include <stdio.h>
class A {
public:
    long a = 0x55AA;
    long b = 0xDEAD;
};

int main(int /*argc*/, char** /*argv[]*/) {
    long *b = new long[2] {0x0L, 0x1L};
    A *a = new A();
    printf("A:%p\n", a);
    printf("B:%p\n", b);
    b[2] = 0xDEAD;
    printf("B2:%p\n", &b[2]);
    printf("0x%lx-0x%lx\n", a->a, a->b);
    return 0;
}

因为 b 的数据大小与对象 a 的数据大小相同，因此在这个程序刚启动分配指针地址时，基本会连在一块，因此 b[2] 越界行为将对象 a 的内容破坏，往往程序运行了很久，内存碎片化增加，就不知道 b[2] 越界操作会破坏哪个对象的内存。

makefile复制代码# ./data/Tester64
A:0xb400007fa7c05020
B:0xb400007fa7c05010
B2:0xb400007fa7c05020
0xdead-0xdead

机器码翻译

本文案例中的 tombstone 文件 PC 跑飞，没有落在 text 段地址上，这里换一份 tombstone 方便说明，我们可以通过编译的方法生成对应的 ELF 文件，即可用 objdump 得到对应的汇编。

bash复制代码signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x40
Cause: null pointer dereference
x0 0000000000000020 x1 b400007bf95f0e00 x2 63692f6863726165 x3 0000000000000008
x4 b400007bf95f0e74 x5 b400007bf8ea36f4 x6 656863732f676e69 x7 732f7269645f616d
x8 db4cf552ad46f717 x9 0000000000000001 x10 00000000000349e0 x11 0000007bc0000000
x12 0000000000000000 x13 0000000000034960 x14 b400007b58d7c4c0 x15 00000000374d2457
x16 0000007ca3543d50 x17 0000007ca35338ec x18 0000007b38c74000 x19 0000000000000020
x20 0000000000000000 x21 0000007b548e9000 x22 0000007b548e9000 x23 b400007bf946ffd0
x24 0000007b548e76c0 x25 0000007b548e9000 x26 0000007b548e7b30 x27 0000007b548e7b18
x28 0000007b548e7a10 x29 0000007b548e7410
lr 0000007a8e4e7980 sp 0000007b548e73e0 pc 0000007a8e4d0e00 pst 0000000060001000

memory near pc (/apex/com.android.appsearch/lib64/libicing.so):
0000007a8e4d0de0 a90557f6f90023f7 9100c3fda9064ff4 .#…W…O……
0000007a8e4d0df0 f94016c8d53bd056 f81f83a8aa0003f3 V.;…@………
0000007a8e4d0e00 350001c839408008 91181c42b0fffde2 ..@9…5….B…
0000007a8e4d0e10 2a1f03e1910023e0 910023f452808ee3 .#…..*…R.#..*
0000007a8e4d0e20 910022809400d695 912b742190fffde1 ….."……!t+.*

编写汇编文件 code.S，内容如下：

复制代码.inst 0xf90023f7
.inst 0xa90557f6
.inst 0xa9064ff4
.inst 0x9100c3fd
.inst 0xd53bd056
.inst 0xf94016c8
.inst 0xaa0003f3
.inst 0xf81f83a8
.inst 0x39408008
.inst 0x350001c8
.inst 0xb0fffde2
.inst 0x91181c42
.inst 0x910023e0
.inst 0x2a1f03e1
.inst 0x52808ee3
.inst 0x910023f4
.inst 0x9400d695
.inst 0x91002280
.inst 0x90fffde1
.inst 0x912b7421

yaml复制代码编译：aarch64-linux-android-as code.S -o code.o
反汇编：aarch64-linux-android-objdump -d code.o

code.o: file format elf64-littleaarch64
Disassembly of section .text:
0000000000000000 <.text>:
0: f90023f7 str x23, [sp, #64]
4: a90557f6 stp x22, x21, [sp, #80]
8: a9064ff4 stp x20, x19, [sp, #96]
c: 9100c3fd add x29, sp, #0x30
10: d53bd056 mrs x22, tpidr_el0
14: f94016c8 ldr x8, [x22, #40]
18: aa0003f3 mov x19, x0
1c: f81f83a8 stur x8, [x29, #-8]
20: 39408008 ldrb w8, [x0, #32]
24: 350001c8 cbnz w8, 5c <.text+0x5c>
28: b0fffde2 adrp x2, fffffffffffbd000 <.text+0xfffffffffffbd000>
2c: 91181c42 add x2, x2, #0x607
30: 910023e0 add x0, sp, #0x8
34: 2a1f03e1 mov w1, wzr
38: 52808ee3 mov w3, #0x477 // #1143
3c: 910023f4 add x20, sp, #0x8
40: 9400d695 bl 35a94 <.text+0x35a94>
44: 91002280 add x0, x20, #0x8
48: 90fffde1 adrp x1, fffffffffffbc000 <.text+0xfffffffffffbc000>
4c: 912b7421 add x1, x1, #0xadd

由于x0=0x0000000000000020，因此在指令0x39408008( ldrb w8, [x0, #32])，会发生读取内存0x40的段错误。

汇编翻译

有些时候我们可能需要手动修改 ELF 文件的机器码达到一些调试的目的，这时候我们就需要知道汇编对应的机器码，去查手册也比较麻烦，这时我们直接编写汇编文件即可。

编写汇编文件 code_asm.S，内容如下：

1 2	python复制代码str x30, [sp, #-16]! str x29, [sp, #-16]!

python复制代码编译：aarch64-linux-android-as code_asm.S -o code_asm.o
反汇编：aarch64-linux-android-objdump -d code_asm.o

code_asm.o: file format elf64-littleaarch64
Disassembly of section .text:
0000000000000000 <.text>:
0: f81f0ffe str x30, [sp, #-16]!
4: f81f0ffd str x29, [sp, #-16]!

案例讲解

错误日志

yaml复制代码Timestamp: 2022-06-07 01:53:32.033409857+0800
Process uptime: 0s
Cmdline: mediaserver64
pid: 1139, tid: 11981, name: NPDecoder >>> mediaserver64 <<<
uid: 1013
tagged_addr_ctrl: 0000000000000001
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7c02d886f0
x0 79748c5e568e2ddc x1 0000007ca13c3618 x2 0000000000000000 x3 0000007ca1291000
x4 0000000001909705 x5 0000000000000000 x6 0000007c02d88808 x7 b60625655bf0252f
x8 0000000000000080 x9 0000007ca126fed7 x10 0000000000000006 x11 0000007bfd0a81fc
x12 9ef8a95ca9649dbe x13 e44782d5ac38720e x14 0000007bfd0a8030 x15 0000001e56307b5c
x16 0000007c95dfdb70 x17 0000007c9844f118 x18 0000007bfaa28000 x19 b400007c13c246d0
x20 0000007c02d88730 x21 b400007c13c67c00 x22 0000000000000415 x23 0000007c02d89000
x24 0000000000000002 x25 b400007c13c246d0 x26 b400007c13c67c00 x27 0000007c02d89000
x28 0000007ca13c2c28 x29 0000007c02d886f0
lr 0000007c02d886f0 sp 0000007c02d886d0 pc 0000007c02d886f0 pst 0000000080001000

backtrace:
#00 pc 00000000000f86f0 [anon:stack_and_tls:11981]

分析

直接原因

less复制代码0000007c'02c90000-0000007c'02d8bfff rw- 0 fc000 [anon:stack_and_tls:11981]
memory near pc ([anon:stack_and_tls:11981]):
0000007c02d886d0 b400007c13c246d0 0000000001909705 .F..|………..
0000007c02d886e0 0000007c02d88700 6f2ab3b40fa2f8ef ….|………*o*
0000007c02d886f0 0000007c02d88750 0000007ca133f8e0 P…|…..3.|…*
0000007c02d88700 0000000000000002 0000000000000000 …………….*
0000007c02d88710 0000000000000415 0000000001909705 …………….*

code.o: file format elf64-littleaarch64
Disassembly of section .text:
0000000000000000 <.text>:

0: 02d886f0 .inst 0x02d886f0 ; undefined
4: 0000007c udf #124

从 tombstone 的 backtrace 信息上看，很明显是PC跑飞了，跑到线程栈地址空间下，
栈内存地址不可运行，因此被拒绝访问而出错，如果有x的权限那么也是错误，会发生 SIGILL 指令错误

栈回溯

从 tombstone 中的 x29 和 SP 寄存器附近的内存中进行栈回溯，由于大小受限，往往无法回溯到栈底，无法完全证明程序就是经过这几个函数。

arduino复制代码memory near x29 ([anon:stack_and_tls:11981]):
0000007c02d886d0 b400007c13c246d0 0000000001909705 .F..|………..【SP = 0x0000007c02d886d0】
0000007c02d886e0 0000007c02d88700 6f2ab3b40fa2f8ef ….|………*o*
0000007c02d886f0 0000007c02d88750 0000007ca133f8e0 P…|…..3.|…【x29 = 0x0000007c02d886f0】
0000007c02d88700 0000000000000002 0000000000000000 …………….*
0000007c02d88710 0000000000000415 0000000001909705 …………….*
0000007c02d88720 0000000000000000 0000007c02d88808 …………|…*
0000007c02d88730 b400007c13c67c00 0000000000000000 .|..|………..*
0000007c02d88740 0000007c02d89000 6f2ab3b40fa2f8ef ….|………*o
0000007c02d88750 0000007c02d88830 0000007ca796ee7c 0…|…|…|…
0000007c02d88760 0000007ca79f3dd8 0000007ca79edb80 .=..|…….|…
0000007c02d88770 0000007c02d89000 b400007c13c04680 ….|….F..|…
0000007c02d88780 0000000000000000 0000000000000002 …………….
0000007c02d88790 b400007c13c67c00 0000000000000000 .|..|………..
0000007c02d887a0 0000000000000000 b400007c13c7c100 …………|…
0000007c02d887b0 0000007c02d88830 0000007ca796d420 0…|… …|…
0000007c02d887c0 0000007c02d88830 0000007ca796d460 0…|…`…|…

这里我们通过 FP(x29) 回溯，如果这个 x29 是有效的，那么 x29 存放的是上一个 Caller 的 FP 寄存器，x29+0x8 的地址存放上一个 Caller 的 LR 寄存器。

0x0000007ca133f8e0 地址落在 /system/lib64/libstagefright.so 的 TEXT 段上。
0000007c'a120e000-0000007c'a128efff r-- 0 81000 /system/lib64/libstagefright.so
0000007c'a128f000-0000007c'a13c0fff r-x 81000 132000 /system/lib64/libstagefright.so
0000007c'a13c1000-0000007c'a13cffff r-- 1b3000 f000 /system/lib64/libstagefright.so
0000007c'a13d0000-0000007c'a13d1fff rw- 1c1000 2000 /system/lib64/libstagefright.so

[14] .text PROGBITS 0000000000081000 00081000
000000000012bed8 0000000000000000 AX 0 0 4096

Funcation_Offset = PC - TEXT_LOAD + .text_offset

(gdb) p /x 0x0000007ca133f8e0-0x7ca128f000+0x81000
$1 = 0x1318e0

(gdb) x /2i 0x1318e0-0x4
0x1318dc <_ZN7android10MediaCodec16queueInputBufferEmmmljPNS_7AStringE+200>: bl 0x1ad390 <_ZN7android8AMessageC1EjRKNS_2spIKNS_8AHandlerEEE@plt>
0x1318e0 <_ZN7android10MediaCodec16queueInputBufferEmmmljPNS_7AStringE+204>: eor x8, x29, x25

(gdb) p _ZN7android10MediaCodec16queueInputBufferEmmmljPNS_7AStringE+200
$2 = (android::status_t (*)(struct android::MediaCodec * const, size_t, size_t, size_t, int64_t, uint32_t,
struct android::AString *)) 0x1318dc <android::MediaCodec::queueInputBuffer(unsigned long, unsigned long, unsigned long, long, unsigned int, android::AString*)+200>

因此0x0000007ca133f8e0所在的函数是android::MediaCodec::queueInputBuffer。
一般我们直接 PC 减去库文件的起始地址即可得到函数的偏移地址。

即： 0x0000007ca133f8e0 - 0x0000007ca120e000

最后这份 tombstone 只能通过 FP 推导出这两个函数，是否正确待取证，这也体现了 tombstone 的局限性，此时我们希望能完整的推导，并取证栈是完整性，需要使用到 coredump 文件进行。

	FP	LR	函数名
0x0000007c02d886f0	0x0000007c02d88750	0x0000007ca133f8e0	android::MediaCodec::queueInputBuffer
0x0000007c02d88750	0x0000007c02d88830	0x0000007ca796ee7c	android::NuPlayer::Decoder::onInputBufferFetched

scss复制代码MTK 的 aee 会将保存一份 minidump ，将 minidump 装载到gdb上回溯。
core-file PROCESS_MINIDUMP
(gdb) bt
#0 0x0000007c02d886f0 in ?? ()
由此可见 GDB 也无法正确回溯这个栈，我们重复前面的步骤在完整的栈上进行计算，可以得到

当前FP	Caller FP	Caller LR	Caller 函数名
0x7c02d886f0	0x0000007c02d88750	0x0000007ca133f8e0	android::MediaCodec::queueInputBuffer
0x7c02d88750	0x0000007c02d88830	0x0000007ca796ee7c	android::NuPlayer::Decoder::onInputBufferFetched
0x7c02d88830	0x0000007c02d888a0	0x0000007ca796c984	android::NuPlayer::Decoder::doRequestBuffers
0x7c02d888a0	0x0000007c02d88920	0x0000007ca7963d48	android::NuPlayer::DecoderBase::onRequestInputBuffers
0x7c02d88920	0x0000007c02d88980	0x0000007ca79717bc	android::NuPlayer::Decoder::handleAnInputBuffer
0x7c02d88980	0x0000007c02d88a20	0x0000007ca7969328	android::NuPlayer::Decoder::onMessageReceived
0x7c02d88a20	0x0000007c02d88a70	0x0000007c95de2874	android::AHandler::deliverMessage
0x7c02d88a70	0x0000007c02d88ad0	0x0000007c95de8608	android::AMessage::deliver
0x7c02d88ad0	0x0000007c02d88b30	0x0000007c95de3bbc	android::ALooper::loop
0x7c02d88b30	0x0000007c02d88ba0	0x0000007ca105907c	android::Thread::_threadLoop
0x7c02d88ba0	0x0000007c02d88c10	0x0000007ca105886c	thread_data_t::trampoline
0x7c02d88c10	0x0000007c02d88c50	0x0000007caaf3be74	__pthread_start
0x7c02d88c50	0x0000007c02d88c80	0x0000007caaedb830	__start_thread

这个线程栈内存能被回溯到 __start_thread 函数，基本可以确定这个栈是可信的，并且最后的 FP 地址存放了 Caller FP 与 Caller LR，并且从汇编的指令流程上是吻合的，可以确定最后的 FP 应该是某个函数的栈顶，记这个函数为 A 函数。

A 函数是谁？

makefile复制代码(gdb) x /12gx 0x7c02d886d0
0x7c02d886d0: 0xb400007c13c246d0 0x0000000001909705 // SP
0x7c02d886e0: 0x0000007c02d88700 0x6f2ab3b40fa2f8ef
此处是 A 函数的栈。
0x7c02d886f0: 0x0000007c02d88750 0x0000007ca133f8e0 // FP
0x7c02d88700: 0x0000000000000002 0x0000000000000000
0x7c02d88710: 0x0000000000000415 0x0000000001909705
0x7c02d88720: 0x0000000000000000 0x0000007c02d88808

当 A 函数运行完成后返回 LR 地址 0x0000007ca133f8e0 (*android* *::MediaCodec::queueInputBuffer)*

注：以下“_ZN7android10MediaCodec16queueInputBufferEmmmljPNS_7AStringE” 用 "android::MediaCodec::queueInputBuffer" 替代

ruby复制代码(gdb) disassemble 0x0000007ca133f8e0-0x20,+0x30
Dump of assembler code from 0x7ca133f8c0 to 0x7ca133f8f0:
0x0000007ca133f8c0 <android::MediaCodec::queueInputBuffer+172>: mov x1, sp
0x0000007ca133f8c4 <android::MediaCodec::queueInputBuffer+176>: mov x0, x26
0x0000007ca133f8c8 <android::MediaCodec::queueInputBuffer+180>: bl 0x7ca13bb130 <_ZNK7android7RefBase9incStrongEPKv@plt>
0x0000007ca133f8cc <android::MediaCodec::queueInputBuffer+184>: mov x2, sp
0x0000007ca133f8d0 <android::MediaCodec::queueInputBuffer+188>: mov x0, x25
0x0000007ca133f8d4 <android::MediaCodec::queueInputBuffer+192>: mov w1, #0x6549 // #25929
0x0000007ca133f8d8 <android::MediaCodec::queueInputBuffer+196>: movk w1, #0x7175, lsl #16
0x0000007ca133f8dc <android::MediaCodec::queueInputBuffer+200>: bl 0x7ca13bb390 <_ZN7android8AMessageC1EjRKNS_2spIKNS_8AHandlerEEE@plt>
0x0000007ca133f8e0 <android::MediaCodec::queueInputBuffer+204>: eor x8, x29, x25
0x0000007ca133f8e4 <android::MediaCodec::queueInputBuffer+208>: cmp x8, #0xfff
0x0000007ca133f8e8 <android::MediaCodec::queueInputBuffer+212>: str x25, [sp, #8]
0x0000007ca133f8ec <android::MediaCodec::queueInputBuffer+216>: b.hi 0x7ca133f8f4 <_ZN7android10MediaCodec16queueInputBufferEmmmljPNS_7AStringE+224> // b.pmore
End of assembler dump.

(gdb) p _ZN7android10MediaCodec16queueInputBufferEmmmljPNS_7AStringE+180
$59 = (android::status_t (*)(android::MediaCodec * const, size_t, size_t, size_t, int64_t, uint32_t,
android::AString *)) 0x7ca133f8c8 <* *android::MediaCodec::queueInputBuffer(unsigned long, unsigned long, unsigned long, long, unsigned int, android::AString*)+180>

这个 A 函数是 android::AMessage::AMessage(unsigned int, android::sp<android::AHandler const> const&)？

A 函数会是 AMessage 的构造方法吗？

less复制代码(gdb) disassemble 0x7ca13bb390
Dump of assembler code for function _ZN7android8AMessageC1EjRKNS_2spIKNS_8AHandlerEEE@plt:
0x0000007ca13bb390 <+0>: adrp x16, 0x7ca13cd000
0x0000007ca13bb394 <+4>: ldr x17, [x16, #992]
0x0000007ca13bb398 <+8>: add x16, x16, #0x3e0
0x0000007ca13bb39c <+12>: br x17
End of assembler dump.

(gdb) x /gx 0x7ca13cd000+0x3e0
0x7ca13cd3e0 <_ZN7android8AMessageC1EjRKNS_2spIKNS_8AHandlerEEE@got.plt>: 0x0000007c95de66a8

(gdb) disassemble 0x0000007c95de66a8
Dump of assembler code for function _ZN7android8AMessageC2EjRKNS_2spIKNS_8AHandlerEEE:
0x0000007c95de66a8 <+0>: stp x29, x30, [sp, #-48]!
0x0000007c95de66ac <+4>: str x21, [sp, #16]
0x0000007c95de66b0 <+8>: stp x20, x19, [sp, #32]
0x0000007c95de66b4 <+12>: mov x29, sp
0x0000007c95de66b8 <+16>: mov x19, x2
0x0000007c95de66bc <+20>: mov w20, w1
0x0000007c95de66c0 <+24>: mov x21, x0
0x0000007c95de66c4 <+28>: bl 0x7c95dfb490 <_ZN7android7RefBaseC2Ev@plt>
0x0000007c95de66c8 <+32>: movi v0.2d, #0x0
0x0000007c95de66cc <+36>: adrp x8, 0x7c95dfd000 <__dso_handle_const>
0x0000007c95de66d0 <+40>: ldr x8, [x8, #2744]
0x0000007c95de66d4 <+44>: str w20, [x21, #16]
0x0000007c95de66d8 <+48>: stur q0, [x21, #24]
0x0000007c95de66dc <+52>: add x8, x8, #0x10
0x0000007c95de66e0 <+56>: stur q0, [x21, #40]
0x0000007c95de66e4 <+60>: mov x0, x21
0x0000007c95de66e8 <+64>: mov x1, x19
0x0000007c95de66ec <+68>: stur q0, [x21, #56]
0x0000007c95de66f0 <+72>: str x8, [x21]
0x0000007c95de66f4 <+76>: str xzr, [x21, #72]
0x0000007c95de66f8 <+80>: ldp x20, x19, [sp, #32]
0x0000007c95de66fc <+84>: ldr x21, [sp, #16]
0x0000007c95de6700 <+88>: ldp x29, x30, [sp], #48
0x0000007c95de6704 <+92>: b 0x7c95dfb950 <_ZN7android8AMessage9setTargetERKNS_2spIKNS_8AHandlerEEE@plt>
End of assembler dump.

这个函数的栈大小为0x30，并且 FP=SP，如果A函数是 AMessage 的构造函数，那么在该函数未退栈时 FP=SP 不成立。

继续往前看栈上内存信息：

makefile复制代码0x7c02d88600: 0xb400007c13c24bd0 0x6f2ab3b40fa2f8ef
0x7c02d88610: 0x0000007c02d88660 0x0000007c95de6510
0x7c02d88620: 0x0000007c02d89000 0x6f2ab3b40fa2f8ef
0x7c02d88630: 0x0000007c02d88670 0x0000007caae98c58
0x7c02d88640: 0x0000007c02d886b0 0x0000007caae9ce40
0x7c02d88650: 0x0000000000000005 0x6f2ab3b40fa2f8ef
0x7c02d88660: 0x0000007c02d886a0 0x0000007caae98c58
0x7c02d88670: 0x0000000000000002 0x0000000000000000
0x7c02d88680: 0x0000000000000415 0xb400007c13c246d0
0x7c02d88690: 0x0000000071756549 0x0000000000000018
0x7c02d886a0: 0x0000007c02d886c0 0x0000007c9dccfb74 operator new(unsigned long)
0x7c02d886b0: 0x0000000000000018 0x0000007caae98c58
0x7c02d886c0: 0x0000007c02d886f0 0x0000007c95de6754

makefile复制代码0x7c02d886d0: 0xb400007c13c246d0 0x0000000001909705 /SP
0x7c02d886e0: 0x0000007c02d88700 0x6f2ab3b40fa2f8ef
此处是 A 函数的栈。
0x7c02d886f0: 0x0000007c02d88750 0x0000007ca133f8e0 // FP
0x7c02d88700: 0x0000000000000002 0x0000000000000000
0x7c02d88710: 0x0000000000000415 0x0000000001909705
0x7c02d88720: 0x0000000000000000 0x0000007c02d88808

地址 0x7c02d886c0 存放的内存正好指向 A 函数 FP 地址，因此这里很可能是 A 函数的下一个函数的栈
函数栈{x29，x30} = {0x0000007c02d886f0，0x0000007c95de6754}

注：以下将字符串"_ZN7android8AMessage9setTargetERKNS_2spIKNS_8AHandlerEEE"更替为"android::AMessage::setTarget"

ruby复制代码(gdb) disassemble 0x0000007c95de6754-0x20,+0x40
Dump of assembler code from 0x7c95de6734 to 0x7c95de6774:
0x0000007c95de6734 <android::AMessage::setTarget+44>: cbz x21, 0x7c95de6880 <android::AMessage::setTarget+376>
0x0000007c95de6738 <android::AMessage::setTarget+48>: mov x20, x1
0x0000007c95de673c <android::AMessage::setTarget+52>: ldr x1, [x21]
0x0000007c95de6740 <android::AMessage::setTarget+56>: mov x0, #0x2ddc // #11740
0x0000007c95de6744 <android::AMessage::setTarget+60>: movk x0, #0x568e, lsl #16
0x0000007c95de6748 <android::AMessage::setTarget+64>: movk x0, #0x8c5e, lsl #32
0x0000007c95de674c <android::AMessage::setTarget+68>: movk x0, #0x7974, lsl #48
0x0000007c95de6750 <android::AMessage::setTarget+72>: bl 0x7c95dfb370 <__cfi_slowpath@plt>
0x0000007c95de6754 <android::AMessage::setTarget+76>: ldr w8, [x21, #16]
0x0000007c95de6758 <android::AMessage::setTarget+80>: str w8, [x19, #20]
0x0000007c95de675c <android::AMessage::setTarget+84>: ldr x21, [x20]
0x0000007c95de6760 <android::AMessage::setTarget+88>: ldr x1, [x21]
0x0000007c95de6764 <android::AMessage::setTarget+92>: mov x0, #0x2ddc // #11740
0x0000007c95de6768 <android::AMessage::setTarget+96>: movk x0, #0x568e, lsl #16
0x0000007c95de676c <android::AMessage::setTarget+100>: movk x0, #0x8c5e, lsl #32
0x0000007c95de6770 <android::AMessage::setTarget+104>: movk x0, #0x7974, lsl #48
End of assembler dump.

(gdb) p _ZN7android8AMessage9setTargetERKNS_2spIKNS_8AHandlerEEE+72
$64 = (void (*)(android::AMessage * const, const android::sp<android::AHandler const> &)) 0x7c95de6750 <android::AMessage::setTarget(android::sp<android::AHandler const> const&)+72>

A函数会是android::AMessage::setTarget？

ruby复制代码(gdb) disassemble 0x0000007c95de6708,+0x30
Dump of assembler code from 0x7c95de6708 to 0x7c95de6738:
0x0000007c95de6708 <android::AMessage::setTarget+0>: sub sp, sp, #0x60
0x0000007c95de670c <android::AMessage::setTarget+4>: stp x29, x30, [sp, #32]
0x0000007c95de6710 <android::AMessage::setTarget+8>: stp x24, x23, [sp, #48]
0x0000007c95de6714 <android::AMessage::setTarget+12>: stp x22, x21, [sp, #64]
0x0000007c95de6718 <android::AMessage::setTarget+16>: stp x20, x19, [sp, #80]
0x0000007c95de671c <android::AMessage::setTarget+20>: add x29, sp, #0x20
0x0000007c95de6720 <android::AMessage::setTarget+24>: mrs x23, tpidr_el0
0x0000007c95de6724 <android::AMessage::setTarget+28>: ldr x8, [x23, #40]
0x0000007c95de6728 <android::AMessage::setTarget+32>: stur x8, [x29, #-8]
0x0000007c95de672c <android::AMessage::setTarget+36>: ldr x21, [x1]
0x0000007c95de6730 <android::AMessage::setTarget+40>: mov x19, x0
0x0000007c95de6734 <android::AMessage::setTarget+44>: cbz x21, 0x7c95de6880 <android::AMessage::setTarget+376>

从汇编看函数栈正是0x60与A函数的栈相等。
回去再看看 AMessage::AMessage 的汇编，可以发现它是退栈后跳转到 android::AMessage::setTarget。

1 2	less复制代码0x0000007c95de6700 <+88>: ldp x29, x30, [sp], #48 0x0000007c95de6704 <+92>: b 0x7c95dfb950 <_ZN7android8AMessage9setTargetERKNS_2spIKNS_8AHandlerEEE@plt>

复制代码x0 79748c5e568e2ddc x1 0000007ca13c3618 x2 0000000000000000 x3 0000007ca1291000
x4 0000000001909705 x5 0000000000000000 x6 0000007c02d88808 x7 b60625655bf0252f
x8 0000000000000080 x9 0000007ca126fed7 x10 0000000000000006 x11 0000007bfd0a81fc
x12 9ef8a95ca9649dbe x13 e44782d5ac38720e x14 0000007bfd0a8030 x15 0000001e56307b5c
x16 0000007c95dfdb70 x17 0000007c9844f118 x18 0000007bfaa28000 x19 b400007c13c246d0
x20 0000007c02d88730 x21 b400007c13c67c00 x22 0000000000000415 x23 0000007c02d89000
x24 0000000000000002 x25 b400007c13c246d0 x26 b400007c13c67c00 x27 0000007c02d89000
x28 0000007ca13c2c28 x29 0000007c02d886f0
lr 0000007c02d886f0 sp 0000007c02d886d0 pc 0000007c02d886f0 pst 0000000080001000

再回看 setTarget 汇编刚好 x0=0x79748c5e568e2ddc，

ruby复制代码0x0000007c95de6740 <android::AMessage::setTarget+56>: mov x0, #0x2ddc // #11740
0x0000007c95de6744 <android::AMessage::setTarget+60>: movk x0, #0x568e, lsl #16
0x0000007c95de6748 <android::AMessage::setTarget+64>: movk x0, #0x8c5e, lsl #32
0x0000007c95de674c <android::AMessage::setTarget+68>: movk x0, #0x7974, lsl #48
0x0000007c95de6750 <android::AMessage::setTarget+72>: bl 0x7c95dfb370 <__cfi_slowpath@plt>

x16 = 0x0000007c95dfdb70与x17= 0x0000007c9844f118 也满足tombstone信息。

sql复制代码(gdb) disassemble 0x7c95dfb370
Dump of assembler code for function __cfi_slowpath@plt:
0x0000007c95dfb370 <+0>: adrp x16, 0x7c95dfd000 <__dso_handle_const>
0x0000007c95dfb374 <+4>: ldr x17, [x16, #2928]
0x0000007c95dfb378 <+8>: add x16, x16, #0xb70
0x0000007c95dfb37c <+12>: br x17
End of assembler dump.

(gdb) x /gx 0x7c95dfd000+0xb70
0x7c95dfdb70 <__cfi_slowpath@got.plt>: 0x0000007c9844f118

less复制代码(gdb) disassemble 0x0000007c9844f118
Dump of assembler code for function __cfi_slowpath(uint64_t, void *):*
0x0000007c9844f118 <+0>: stp x29, x30, [sp, #-16]!*
0x0000007c9844f11c <+4>: mov x29, sp*
0x0000007c9844f120 <+8>: lsr x8, x1, #17*
0x0000007c9844f124 <+12>: and x8, x8, #0x7ffffffffe*
0x0000007c9844f128 <+16>: mov w9, #0x80000000 // #-2147483648*
0x0000007c9844f12c <+20>: cmp x8, x9*
0x0000007c9844f130 <+24>: b.hi 0x7c9844f14c <__cfi_slowpath(uint64_t, void*)+52> // b.pmore
0x0000007c9844f134 <+28>: adrp x9, 0x7c98452000 <_ZL19shadow_base_storage>
0x0000007c9844f138 <+32>: ldr x9, [x9]
0x0000007c9844f13c <+36>: ldrh w8, [x9, x8]
0x0000007c9844f140 <+40>: cmp w8, #0x1
0x0000007c9844f144 <+44>: b.eq 0x7c9844f15c <__cfi_slowpath(uint64_t, void *)+68> // b.none*
0x0000007c9844f148 <+48>: cbnz w8, 0x7c9844f164 <__cfi_slowpath(uint64_t, void*)+76>
0x0000007c9844f14c <+52>: xpaclri
0x0000007c9844f150 <+56>: mov x2, xzr
0x0000007c9844f154 <+60>: mov x3, x30
0x0000007c9844f158 <+64>: bl 0x7c9844f2a0 <__loader_cfi_fail@plt>
0x0000007c9844f15c <+68>: ldp x29, x30, [sp], #16
0x0000007c9844f160 <+72>: ret
0x0000007c9844f164 <+76>: and x9, x1, #0xfffffffffffc0000
0x0000007c9844f168 <+80>: sub x8, x9, x8, lsl #12
0x0000007c9844f16c <+84>: add x3, x8, #0x42, lsl #12
0x0000007c9844f170 <+88>: mov x2, xzr
0x0000007c9844f174 <+92>: ldp x29, x30, [sp], #16
0x0000007c9844f178 <+96>: br x3
End of assembler dump.

因此 A 函数的栈是 android::AMessage::setTarget(android::sp<android::AHandler const> const&)

计算汇编走向

根据 tombstone 最后的栈地址 SP=0x0000007c02d886d0 说明函数 __cfi_slowpath(uint64_t, void ) 已经退栈。

makefile复制代码0x7c02d88620: 0x0000007c02d89000 0x6f2ab3b40fa2f8ef
0x7c02d88630: 0x0000007c02d88670 0x0000007caae98c58
0x7c02d88640: 0x0000007c02d886b0 0x0000007caae9ce40
0x7c02d88650: 0x0000000000000005 0x6f2ab3b40fa2f8ef
je_malloc
0x7c02d88660: 0x0000007c02d886a0 0x0000007caae98c58
0x7c02d88670: 0x0000000000000002 0x0000000000000000
0x7c02d88680: 0x0000000000000415 0xb400007c13c246d0
0x7c02d88690: 0x0000000071756549 0x0000000000000018

malloc(size_t)
0x7c02d886a0: 0x0000007c02d886c0 0x0000007c9dccfb74 operator new(unsigned long)
0x7c02d886b0: 0x0000000000000018 0x0000007caae98c58

__cfi_slowpath(uint64_t, void*)
0x7c02d886c0: 0x0000007c02d886f0 0x0000007c95de6754
0x7c02d886d0: 0xb400007c13c246d0 0x0000000001909705
0x7c02d886e0: 0x0000007c02d88700 0x6f2ab3b40fa2f8ef

android::AMessage::setTarget(android::sp<android::AHandler const> const&)
0x7c02d886f0: 0x0000007c02d88750 0x0000007ca133f8e0
0x7c02d88700: 0x0000000000000002 0x0000000000000000
0x7c02d88710: 0x0000000000000415 0x0000000001909705
0x7c02d88720: 0x0000000000000000 0x0000007c02d88808
0x7c02d88730: 0xb400007c13c67c00 0x0000000000000000
0x7c02d88740: 0x0000007c02d89000 0x6f2ab3b40fa2f8ef

android::MediaCodec::queueInputBuffer(unsigned long, unsigned long, unsigned long, long, unsigned int, android::AString*)
0x7c02d88750: 0x0000007c02d88830 0x0000007ca796ee7c
0x7c02d88760: 0x0000007ca79f3dd8 0x0000007ca79edb80
0x7c02d88770: 0x0000007c02d89000 0xb400007c13c04680
0x7c02d88780: 0x0000000000000000 0x0000000000000002
0x7c02d88790: 0xb400007c13c67c00 0x0000000000000000
0x7c02d887a0: 0x0000000000000000 0xb400007c13c7c100

其中恢复其调用栈如下：

arduino复制代码backtrace:
unknown？
android::AMessage::setTarget(android::sp<android::AHandler const> const&)
android::MediaCodec::queueInputBuffer(unsigned long, unsigned long, unsigned long, long, unsigned int, android::AString*)
...

__cfi_slowpath函数有两处退栈相关。

ini复制代码第一部分：
0x0000007c9844f14c <+52>: xpaclri
0x0000007c9844f150 <+56>: mov x2, xzr
0x0000007c9844f154 <+60>: mov x3, x30
0x0000007c9844f158 <+64>: bl 0x7c9844f2a0 <__loader_cfi_fail@plt>
0x0000007c9844f15c <+68>: ldp x29, x30, [sp], #16
0x0000007c9844f160 <+72>: ret

less复制代码第二部分：
0x0000007c9844f164 <+76>: and x9, x1, #0xfffffffffffc0000
0x0000007c9844f168 <+80>: sub x8, x9, x8, lsl #12
0x0000007c9844f16c <+84>: add x3, x8, #0x42, lsl #12
0x0000007c9844f170 <+88>: mov x2, xzr
0x0000007c9844f174 <+92>: ldp x29, x30, [sp], #16
0x0000007c9844f178 <+96>: br x3

如果走的是第一部分退栈，那么 x16 和 x17 将与 tombstone 不符合，因此可以确定走的是第二部分。
而这里会跳转至 x3，可以看下当前 tombstone 里 x3=0x0000007ca1291000 是否为一个有效的函数地址。

less复制代码(gdb) disassemble 0x0000007ca1291000,+0x40
Dump of assembler code from 0x7ca1291000 to 0x7ca1291040:
0x0000007ca1291000 <__cfi_check+0>: str x30, [sp, #-16]!
0x0000007ca1291004 <__cfi_check+4>: mov x8, #0x48f1 // #18673
0x0000007ca1291008 <__cfi_check+8>: movk x8, #0xd799, lsl #16
0x0000007ca129100c <__cfi_check+12>: movk x8, #0xcf94, lsl #32
0x0000007ca1291010 <__cfi_check+16>: movk x8, #0xfc57, lsl #48
0x0000007ca1291014 <__cfi_check+20>: cmp x0, x8
0x0000007ca1291018 <__cfi_check+24>: b.le 0x7ca1291100 <__cfi_check+256>
0x0000007ca129101c <__cfi_check+28>: mov x8, #0xd5c9 // #54729
0x0000007ca1291020 <__cfi_check+32>: movk x8, #0x5fef, lsl #16
0x0000007ca1291024 <__cfi_check+36>: movk x8, #0x22f2, lsl #32
0x0000007ca1291028 <__cfi_check+40>: movk x8, #0x4e31, lsl #48
0x0000007ca129102c <__cfi_check+44>: cmp x0, x8
0x0000007ca1291030 <__cfi_check+48>: b.gt 0x7ca12911f4 <__cfi_check+500>
0x0000007ca1291034 <__cfi_check+52>: mov x8, #0x90ef // #37103
0x0000007ca1291038 <__cfi_check+56>: movk x8, #0x3c9, lsl #16
0x0000007ca129103c <__cfi_check+60>: movk x8, #0x8d30, lsl #32

这个函数非常的大，但有规律，很显然先将 x8与x0 作比较，并且数值与 tombstone 中
x0=0x79748c5e568e2ddc 类似，那么我们可以搜索部分关键字找到相应的 case。

less复制代码0x0000007ca12920b4 <+4276>: mov x8, #0x2ddc // #11740
0x0000007ca12920b8 <+4280>: movk x8, #0x568e, lsl #16
0x0000007ca12920bc <+4284>: movk x8, #0x8c5e, lsl #32
0x0000007ca12920c0 <+4288>: movk x8, #0x7974, lsl #48
0x0000007ca12920c4 <+4292>: cmp x0, x8
0x0000007ca12920c8 <+4296>: b.eq 0x7ca129576c <__cfi_check+18284> // b.none

csharp复制代码0x0000007ca129576c <+18284>: adrp x8, 0x7ca13c2000 <_ZTVN7android17BufferChannelBaseE+24>
0x0000007ca1295770 <+18288>: add x8, x8, #0xc28
0x0000007ca1295774 <+18292>: sub x8, x1, x8
0x0000007ca1295778 <+18296>: sub x8, x8, #0x630
0x0000007ca129577c <+18300>: ror x8, x8, #4
0x0000007ca1295780 <+18304>: cmp x8, #0x5a
0x0000007ca1295784 <+18308>: b.hi 0x7ca1296680 <__cfi_check+22144> // b.pmore

tombstone 中 x9=0x0000007ca126fed7

1
2
3

csharp复制代码0x0000007ca1295788 <+18312>: adrp x9, 0x7ca126f000 <_ZL5__txt+844>
0x0000007ca129578c <+18316>: add x9, x9, #0xed7
0x0000007ca1295790 <+18320>: b 0x7ca12963a4 <__cfi_check+21412>

tombstone 中x8=0x0000000000000080

1
2
3

less复制代码0x0000007ca12963a4 <+21412>: ldrb w8, [x9, x8]
0x0000007ca12963a8 <+21416>: tbnz w8, #7, 0x7ca1296644 <__cfi_check+22084>
0x0000007ca12963ac <+21420>: b 0x7ca1296680 <__cfi_check+22144>

1 2	ini复制代码0x0000007ca1296644 <+22084>: ldr x30, [sp], #16 0x0000007ca1296648 <+22088>: ret

最后在此处退栈回到 android::AMessage::setTarget ，然后 PC=LR=0x0000007c02d886f0 发生段错误。

结论

不难发现一个细节 0x7c02d886c0 地址上存储的内容是有问题的。

makefile复制代码__cfi_slowpath(uint64_t, void*)
0x7c02d886c0: 0x0000007c02d886f0 0x0000007c95de6754

0x7c02d886d0: 0xb400007c13c246d0 0x0000000001909705
0x7c02d886e0: 0x0000007c02d88700 0x6f2ab3b40fa2f8ef

android::AMessage::setTarget(android::sp<android::AHandler const> const&)
0x7c02d886f0: 0x0000007c02d88750 0x0000007ca133f8e0
0x7c02d88700: 0x0000000000000002 0x0000000000000000
0x7c02d88710: 0x0000000000000415 0x0000000001909705
0x7c02d88720: 0x0000000000000000 0x0000007c02d88808

ini复制代码0x0000007c9844f118 < __cfi_slowpath +0>: stp x29, x30, [sp, #-16]!
压栈应该是 0x7c02d886c0: 0x0000007c02d886f0 0x0000007c95de6754
0x0000007c9844f11c < __cfi_slowpath +4>: mov x29, sp
...
0x0000007c9844f174 < __cfi_slowpath +92>: ldp x29, x30, [sp], #16
0x0000007c9844f178 < __cfi_slowpath +96>: br x3
0x0000007ca1291000 <__cfi_check+0>: str x30, [sp, #-16]!
压栈应该是 0x7c02d886c0: 0x0000007c95de6754 0x0000007c95de6754
...
0x0000007ca1296644 < __cfi_check +22084>: ldr x30, [sp], #16
0x0000007ca1296648 < __cfi_check +22088>: ret

(gdb) p /t 0xf81f0ffe 【str x30, [sp, #-16]!】
$5 = 11111000000111110000111111111110
(gdb) p /t 0xf81f0ffd 【str x29, [sp, #-16]!】
$6 = 11111000000111110000111111111101

因此能符合 tombstone 信息，只有此处指令异常导致。

错误模拟

yaml复制代码# ps -ef | grep "medias"
media 1145 1 0 01:35:04 ? 00:00:06 mediaserver64
mediacodec 1223 1 0 01:35:04 ? 00:00:01 media.swcodec oid.media.swcodec/bin/mediaswcodec

# cat /proc/1145/maps | grep "libstagefright.so"
7abb428000-7abb4a9000 r--p 00000000 fe:05 84399283 /system/lib64/libstagefright.so
7abb4a9000-7abb5db000 r-xp 00081000 fe:05 84399283 /system/lib64/libstagefright.so
7abb5db000-7abb5ea000 r--p 001b3000 fe:05 84399283 /system/lib64/libstagefright.so
7abb5ea000-7abb5ec000 rw-p 001c1000 fe:05 84399283 /system/lib64/libstagefright.so

PC=0x7abb428000+0x83000
修改机器码模拟报错场景。
# ./data/memory_get64 1145 0x7abb4ab000
pid 1145, target 0x7abb4ab000
0xd2891e28f81f0ffe

# ./data/memory_set64 1145 0x7abb4ab000 0xd2891e28 0xf81f0ffd
pid 1145, target 0x7abb4ab000, val 0xd2891e28f81f0ffd

06-27 23:10:07.311 1145 1145 F libc : Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7fdc95f510 in tid 1145 (mediaserver64), pid 1145 (mediaserver64)
06-27 23:10:07.579 27515 27515 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
06-27 23:10:07.579 27515 27515 F DEBUG : Revision: '0'
06-27 23:10:07.579 27515 27515 F DEBUG : ABI: 'arm64'
06-27 23:10:07.579 27515 27515 F DEBUG : Timestamp: 2022-06-27 23:10:07.361670464+0800
06-27 23:10:07.579 27515 27515 F DEBUG : Process uptime: 0s
06-27 23:10:07.580 27515 27515 F DEBUG : Cmdline: mediaserver64
06-27 23:10:07.580 27515 27515 F DEBUG : pid: 1145, tid: 1145, name: mediaserver64 >>> mediaserver64 <<<
06-27 23:10:07.580 27515 27515 F DEBUG : uid: 1013
06-27 23:10:07.580 27515 27515 F DEBUG : tagged_addr_ctrl: 0000000000000001
06-27 23:10:07.580 27515 27515 F DEBUG : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7fdc95f510
06-27 23:10:07.580 27515 27515 F DEBUG : x0 bf2d51af2cdcf7a8 x1 0000007abb5df510 x2 0000000000000000 x3 0000007abb4ab000
06-27 23:10:07.580 27515 27515 F DEBUG : x4 0065006300690076 x5 7600690063006500 x6 0065006300690076 x7 b400007ac2afd3c8
06-27 23:10:07.580 27515 27515 F DEBUG : x8 0000000000000003 x9 0000007abb489b40 x10 0000000000000002 x11 0000000000000001
06-27 23:10:07.580 27515 27515 F DEBUG : x12 0000000000000000 x13 0000007aac820058 x14 0000000000000010 x15 0000000000000010
06-27 23:10:07.580 27515 27515 F DEBUG : x16 0000007ab0cbd538 x17 0000007ac1210118 x18 0000007ac3726000 x19 0000007fdc95f5d0
06-27 23:10:07.580 27515 27515 F DEBUG : x20 b400007a26e03048 x21 0000007ac13b1b98 x22 0000007ab0cadc50 x23 0000007ac2d13000
06-27 23:10:07.580 27515 27515 F DEBUG : x24 0000007fdc95f470 x25 b400007ac2aea1c4 x26 0000000000000000 x27 0000000000000479
06-27 23:10:07.580 27515 27515 F DEBUG : x28 0000000000000000 x29 0000007fdc95f510
06-27 23:10:07.580 27515 27515 F DEBUG : lr 0000007fdc95f510 sp 0000007fdc95f440 pc 0000007fdc95f510 pst 0000000080001000
06-27 23:10:07.580 27515 27515 F DEBUG : backtrace:
06-27 23:10:07.580 27515 27515 F DEBUG : #00 pc 000000000001f510 [stack]

Coredump寄存器恢复栈

通过readelf读取MINIDUMP文件，保存寄存器上下文在ELF文件的第一个节中。

python复制代码Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x000000000000fb28 0x0000000000000000 0x0000000000000000
0x00000000000032cc 0x0000000000000000 0x0
LOAD 0x0000000000013000 0x0000005ffabc7000 0x0000000000000000
0x0000000000001000 0x0000000000001000 R 0x0

用hexedit工具打开MINIDUMP文件找到寄存器地址。

erlang复制代码0000FB20 00 00 00 00 00 00 00 00 05 00 00 00 88 01 00 00 ................
0000FB30 01 00 00 00 43 4F 52 45 00 00 00 00 00 00 00 00 ....CORE........
0000FB40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000FB50 00 00 00 00 00 00 00 00 00 00 00 00 CD 2E 00 00 ................
0000FB60 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
0000FB70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000FB80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000FB90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000FBA0 00 00 00 00 00 00 00 00 00 00 00 00 DC 2D 8E 56 .............-.V
0000FBB0 5E 8C 74 79 18 36 3C A1 7C 00 00 00 00 00 00 00 ^.ty.6<.|.......
0000FBC0 00 00 00 00 00 10 29 A1 7C 00 00 00 05 97 90 01 ......).|.......
0000FBD0 00 00 00 00 00 00 00 00 00 00 00 00 08 88 D8 02 ................
0000FBE0 7C 00 00 00 2F 25 F0 5B 65 25 06 B6 80 00 00 00 |.../%.[e%......
0000FBF0 00 00 00 00 D7 FE 26 A1 7C 00 00 00 06 00 00 00 ......&.|.......
0000FC00 00 00 00 00 FC 81 0A FD 7B 00 00 00 BE 9D 64 A9 ........{.....d.
0000FC10 5C A9 F8 9E 0E 72 38 AC D5 82 47 E4 30 80 0A FD \....r8...G.0...
0000FC20 7B 00 00 00 5C 7B 30 56 1E 00 00 00 70 DB DF 95 {...\{0V....p...
0000FC30 7C 00 00 00 18 F1 44 98 7C 00 00 00 00 80 A2 FA |.....D.|.......
0000FC40 7B 00 00 00 D0 46 C2 13 7C 00 00 B4 30 87 D8 02 {....F..|...0...
0000FC50 7C 00 00 00 00 7C C6 13 7C 00 00 B4 15 04 00 00 |....|..|.......
0000FC60 00 00 00 00 00 90 D8 02 7C 00 00 00 02 00 00 00 ........|.......
0000FC70 00 00 00 00 D0 46 C2 13 7C 00 00 B4 00 7C C6 13 .....F..|....|..
0000FC80 7C 00 00 B4 00 90 D8 02 7C 00 00 00 28 2C 3C A1 |.......|...(,<.
0000FC90 7C 00 00 00 F0 86 D8 02 7C 00 00 00 F0 86 D8 02 |.......|...Tg..
0000FCA0 7C 00 00 00 D0 86 D8 02 7C 00 00 00 F0 86 D8 02 |.......|...Tg..
0000FCB0 7C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |...............
0000FCC0 00 00 00 00 05 00 00 00 88 00 00 00 03 00 00 00 ................

上图绿色为LR和PC，将它们修改为正确的返回地址0x0000007c95de6754

1
2
3

erlang复制代码0000FC90 7C 00 00 00 F0 86 D8 02 7C 00 00 00 54 67 DE 95 |.......|...Tg..
0000FCA0 7C 00 00 00 D0 86 D8 02 7C 00 00 00 54 67 DE 95 |.......|...Tg..
0000FCB0 7C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |...............

重新将恢复后的MINIDUMP装载到gdb上即可恢复callstack。

arduino复制代码(gdb) bt
#0 android::AHandler::id (this=0xb400007c13c67c00)
#1 android::AMessage::setTarget (this=0xb400007c13c246d0, handler=...)
#2 0x0000007ca133f8e0 in android::MediaCodec::queueInputBuffer (this=0xb400007c13c67c00, index=2, offset=0, size=1045, presentationTimeUs=26253061, flags=0, errorDetailMsg=0x7c02d88808)
#3 0x0000007ca796ee7c in android::NuPlayer::Decoder::onInputBufferFetched (this=0xb400007c13c7c100, msg=...)
#4 0x0000007ca796c984 in android::NuPlayer::Decoder::doRequestBuffers (this=0xb400007c13c7c100)
#5 0x0000007ca7963d48 in android::NuPlayer::DecoderBase::onRequestInputBuffers (this=0xb400007c13c7c100)
#6 0x0000007ca79717bc in android::NuPlayer::Decoder::handleAnInputBuffer (this=0xb400007c13c7c100, index=2)
#7 0x0000007ca7969328 in android::NuPlayer::Decoder::onMessageReceived (this=0xb400007c13c7c100, msg=...)
#8 0x0000007c95de2874 in android::AHandler::deliverMessage (this=0xb400007c13c7c100, msg=...)
#9 0x0000007c95de8608 in android::AMessage::deliver (this=0xb400007c13c24c70)
#10 0x0000007c95de3bbc in android::ALooper::loop (this=<optimized out>)
#11 0x0000007ca105907c in android::Thread::_threadLoop (user=user@entry=0xb400007cadca8fc0)
#12 0x0000007ca105886c in thread_data_t::trampoline (t=<optimized out>)
#13 0x0000007caaf3be74 in __pthread_start (arg=0x7c02d88cb0)
#14 0x0000007caaedb830 in __start_thread (fn=0x7caaf3bda4 <__pthread_start(void*)>, arg=0x7c02d88cb0)

微信公众号链接：mp.weixin.qq.com/s/YDhqP_ZkS…

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有