半夜两点半手机震动某公有崩溃监控平台推送了一条报警某图像处理Demo在线上设备出现了native crash率上升。我打开详情页第一眼看到的不是堆栈不是机型分布而是一行看起来非常信息密集的日志——signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000000。很多Android开发者到了这一步就卡住了因为平时写Java层代码根本不会直面signal这种东西但native crash排查恰恰是从这一行开始的。这篇内容我会把Android native crash里signal信号量的含义彻底讲透它为什么会出现、每个信号背后对应什么类型的崩溃、看到不同信号该怎么往下查。内容不会只停在信号表背熟的层面还会给出真实的排查链路和工具操作方式希望对正在做NDK开发、音视频处理或者集成了第三方C/C库的朋友有价值。1. 崩溃日志里的signal第一眼就要看懂的那行字1.1 一份典型的native crash日志拆解Android发生native crash时系统通常会在logcat里输出一份简化的tombstone信息并在/data/tombstones或通过崩溃监控SDK汇总一份完整报告。完整报告打开后样貌大概是这样的已脱敏*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** pid: 28412, tid: 28432, name: RenderThread com.example.app signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000000 Cause: null pointer dereference r0 0000000000000000 r1 0000007d5988a0c0 r2 0000000000000004 r3 0000007d5988a0c0 r4 0000000000000000 r5 0000007d5988a0c8 pc 0000007d5988a1a0 sp 0000007d5988a0c0 backtrace: #00 pc 00000000000012c0 /data/app/.../libnative-lib.so (offset 0x12c0) #01 pc 0000000000001480 /data/app/.../libnative-lib.so (Java_com_example_app_NativeLib_processFrame) #02 pc 0000000000007880 /system/lib64/libart.so (art::...)重点看这几处pid/tid/name崩溃发生的进程和线程name直接告诉你崩溃跑在哪个线程比如这里的RenderThread对判断是不是渲染链路问题非常关键。signal 11 (SIGSEGV)本次崩溃的信号。11是信号值SIGSEGV是宏名这两个必须一起看。code 1 (SEGV_MAPERR)同一个信号下的细分原因码。SEGV_MAPERR意思是访问了根本没有映射的地址。fault addr 0x0000000000000000触发异常时的地址。这里是0基本就是空指针读写跑不掉了。backtrace原始栈帧需要用符号化工具还原成函数名和行号。所以读崩溃日志的正确顺序不是直奔backtrace而是先把signal code fault addr这三行连起来看。这三行能直接告诉你进程死在哪一类问题上后面查代码才有方向。1.2 signal、code、fault addr 三者的联动关系signal的值是有限的但同一个signal出现时code往往能给出更精确的切入信息。我整理了Android native crash里常见的信号值和对应codesignal值宏名含义常见细分codeAndroid崩溃中的典型场景4SIGILL非法指令ILL_ILLOPC / ILL_ILLOPN执行了CPU不支持的指令、函数指针跳飞5SIGTRAP陷阱/断点无特殊细分调试器干预、__builtin_trap、某些assert6SIGABRT主动终止无特殊细分abort、堆损坏检测、ART_JNI校验失败7SIGBUS总线错误BUS_ADRALN / BUS_ADRERR未对齐访存、mmap文件被截断后继续访问8SIGFPE算术异常FPE_INTDIV / FPE_INTOVF整数除零、整数溢出10SIGUSR1用户自定义无业务自定义比较少出现在崩溃报告11SIGSEGV段错误SEGV_MAPERR / SEGV_ACCERR空指针、野指针、释放后访问、越界31SIGSYS非法系统调用SYS_SECCOMPseccomp限制下调用非白名单系统调用光看这张表仍然不够还要学会把三个字段放在一起推理。举个例子SIGSEGV SEGV_MAPERR fault addr 0x0十有八九是空指针解引用。SIGSEGV SEGV_ACCERR fault addr 0x...地址是存在的但权限不对典型的是往只读页写入比如往字符串常量区写数据。SIGBUS BUS_ADRALN fault addr 0x...地址在未对齐的边界上ARM设备上特别常见。SIGBUS BUS_ADRERR fault addr 0x...访问了mmap映射范围之外的物理地址常见于文件被截断后还在读映射页。关于fault addr还有一个非常实用的判断技巧如果fault addr和PC寄存器值接近说明进程可能是跳到这个地址执行时炸的比如函数指针被写坏如果PC正常、fault addr是某个数据地址那这就是一次普通的内存读写问题。这个区分能帮你少走很多弯路。日常工程里一份完整tombstone的Cause字段比如null pointer dereference其实是根据signal和code自动生成的提示但这个字段只能当参考最终还是要靠backtrace确认。2. Linux信号机制与Android的适配signal从来不是随便发出来的2.1 信号的三类来源内核异常、主动abort、进程间通知要理解signal必须先想清楚一个问题这个信号到底是谁发出的信号的来源基本可以分成三类。第一类是硬件异常经内核转化。CPU执行指令时发生页错误、对齐检查、除零等异常CPU会触发对应的异常处理流程内核发现这个异常属于某个用户态进程便把这个异常转化为SIGSEGV、SIGBUS、SIGFPE之类的信号发给该进程。这类信号有一个特点它是同步的并且由正在执行的线程当场产生跟当前指令强相关。第二类是用户态代码主动抛出。最常见的例子是调用abort()它会向当前进程发送SIGABRT。为什么代码会主动调abort因为程序内部某处检测到状态已经无法继续比如malloc检测到堆元数据被破坏、C运行时抛出未被捕获的异常后调用std::terminate、Android的ART虚拟机在做JNI校验时发现类型不匹配都会走主动abort这条路。第三类是进程间发送的信号。别的进程通过kill()系统调用给崩溃进程发信号或者用户在shell里执行kill -6 pid手动触发。这种在线上crash里相对少见但一旦出现需要先怀疑是不是有外部监督进程在kill你的App再回头看自己的代码。三类来源对应着完全不同的排查方向如果是硬件异常转信号主要查代码里的内存访问指令如果是主动abort主要查底层库或运行时的校验信息如果是外部信号主要查进程管理和业务守护逻辑。2.2 Android和标准Linux的差异bionic、ART与debuggerdAndroid的native层基于Linux但它的libc是bionic不是glibc这导致崩溃行为有不少差异。bionic的堆分配器比如现代Android上的scudo内置了非常强的完整性检查。如果你在某个线程里把一块buffer越界写穿了破坏到了相邻chunk的元数据下一次分配或释放时分配器会发现异常并主动调用abort。这种崩溃在tombstone里通常会有一行Abort message直接把真正的原因写出来比如heap corruption detected by scudo。所以我一直建议身边做native开发的同事遇到SIGABRT先不要急着看backtrace第一时间展开找Abort message它经常是定位的金钥匙。ART虚拟机也会介入信号处理。当你用JNI从Java调用native函数时如果native代码访问了JNI引用之外的野指针ART的JNI检查可能先于内核汇报错误反过来如果native崩溃发生ART会在崩溃回调里把信号信息翻译给Java层的Thread.setUncaughtExceptionHandler这就是很多崩溃SDK能同时拿到Java和native堆栈的原因。Android上的崩溃收集还有一个关键角色debuggerd。进程收到崩溃信号后系统会唤醒debuggerdAndroid 8.0之后是userdebuggerd由它采集寄存器、加载的so列表、backtrace并写成tombstone文件。这也是为什么我们在logcat里能看到完整的*** *** ***格式日志而不是只有一行signal信息。2.3 同步信号与异步信号同样的信号值完全不同的排查方向很多新手容易忽略一个点同样是SIGABRT可能是当前线程自己abort也可能是别的线程在崩溃检查中abort两者在backtrace上表现出来完全不同。SIGSEGV、SIGBUS、SIGILL、SIGFPE这类由当前指令触发的信号通常是同步信号信号到达的线程就是出问题的线程所以直接沿着该线程的backtrace查就行。SIGABRT、SIGTERM、SIGKILL这类既有主动触发也有外部触发的信号往往是异步的你需要额外注意崩溃线程可能不是元凶线程真正的问题可能发生在另一个线程的检查点。我在工程里遇到过很多次这样的情况SIGABRT的backtrace开头永远是abort - __pthread_kill - raise这组栈再往下才会看到业务帧。很多刚入门的同学看到__pthread_kill就懵了其实这是正常的因为abort本身就是一套固定的系统调用链。真正该看的是业务栈帧里哪一行代码触发了abort以及Abort message里写了什么。3. 高频信号逐个拆SIGSEGV、SIGABRT、SIGBUS、SIGILL、SIGFPE3.1 SIGSEGV空指针、野指针、释放后访问、栈溢出SIGSEGV是native crash里占比最大的信号没有之一。它表示进程访问了一个没有权限或没有映射的内存地址。现实中遇到最多的是几种情况第一种是空指针解引用。fault addr通常接近0x0code是SEGV_MAPERRCrash日志里的Cause常写null pointer dereference。Java层空指针会直接抛NullPointerException但native层不会它就是干净的信号。第二种是野指针和已经释放的栈内存地址。指针变量里存了一个随机垃圾值指向的区域没有映射fault addr往往是某个看起来不太正常的小地址。第三种是典型的use-after-free内存被free之后指针没有置空后续又去读写如果这块地址被回收并重新映射可能报SEGV_MAPERR或SEGV_ACCERR具体取决于分配器怎么处置这块区域。还有一种极其容易忽略的情况是栈溢出。线程栈是有上限的如果递归过深或者栈上开了超大数组线程会顶到栈底以外的未映射区域产生SIGSEGV。这种崩溃的识别特征很有意思fault addr会非常靠近某个映射区域的边界而且在backtrace里你经常能看到连续多帧指向同一个函数典型的递归帧。排查SIGSEGV时我强烈建议把tombstone里附带的maps段打开看一眼把fault addr落到内存地图上它落在堆区栈区某个so的只读段还是完全未映射的虚空落点不同问题性质完全不同。3.2 SIGABRT主动认错的崩溃答案可能写在Abort message里SIGABRT是第二常见的崩溃信号但它和SIGSEGV的本质不同在于极端地说SIGABRT其实是系统在说这个程序已经被判定没救了主动按下终止键而不是踩到地雷。很多C开发者会遇到一种典型情况线程里抛出了异常但外层没有catchC运行时找不到对应的异常处理器于是调用std::terminate()terminate内部再走abort。这种崩溃看起来就像业务代码没有异常保护。另一个高频触发点是bionic加固后的堆检测。比如你用一个指针往堆块之外多写了一个字节scudo分配器很可能在某个mtx上检测到破坏直接abortAbort message里会带有堆损坏的提示。ART虚拟机也会触发SIGABRT。比如你在JNI层调用了GetFieldID但传进去的字段名和Java类里的实际字段对不上或者把jclass误传给某个需要jobject参数的函数ART的CheckJNI机制会输出一条详细的错误信息然后abort。这种崩溃的backtrace通常能直接看到art::JavaVMExt::JniAbort之类的帧。遇到SIGABRT操作顺序应该是先展开找Abort message把这一行文字完整复制出来搜索大部分情况下能直接定位到代码附近的检查点如果找不到Abort message再去看backtrace里的业务栈帧重点找对abort()、__stack_chk_fail、std::terminate、art::*Jni*的调用来源。3.3 SIGBUS与SIGILL对齐与指令集的坑SIGBUS在Android真机上比很多人想象中常见。ARM架构对内存对齐要求严格当你试图通过一个int*去读一个只按2字节对齐的地址时CPU会报总线错误。这种崩溃在把二进制数据反序列化成结构体时最典型从网络或文件里读到一个字节流buffer直接把buffer强转成结构体指针然后访问结构体里的int字段。很多本地产物的buffer恰好是8字节对齐的所以测试时完全正常但另一台设备上buffer首地址只按4字节对齐线上就开始崩。另一种SIGBUS是mmap文件映射后续问题。比如你把一个文件mmap到内存然后另一线程把文件截断了你再去访问映射区域的某个页内核找不到对应的物理页就会发SIGBUS。这类崩溃的code通常是BUS_ADRERRfault addr落在文件映射区域内。解决办法是在访问映射页之前主动校验文件长度同时避免并发截断映射文件。SIGILL则是CPU根本不认识这段指令。常见原因包括二进制so用的是当前设备CPU不支持的扩展指令集比如在老旧设备上跑了带高级SIMD指令的代码、函数指针被写坏后跳到非代码区域执行、以及部分加壳/混淆so在运行期自行修改指令导致解析失败。排查SIGILL时需要把崩溃点附近的几种指令集特性和设备型号列出来做交叉对比经常能发现是某类较老设备专属的崩溃。3.4 SIGFPE与SIGSYS数学异常和系统调用的边界SIGFPE名字里带“浮点”实际最常见的触发却是整数除零。在C/C里直接写int a 100 / 0并不会像Java那样抛异常而是CPU产生算术异常内核转成SIGFPE。代码里如果存在外部传入的除数变量一定要做非零校验。SIGSYS相对少见但一旦遇到就非常让人头疼。它的经典触发场景是进程被seccomp过滤器约束后调用了某个不在白名单里的系统调用。Android系统组件和部分厂商ROM会启用seccomp策略如果你的so为了某些目的直接使用了较新的系统调用而当前设备内核配合的seccomp策略不允许就会直接收到SIGSYS。这种崩溃通常跟特定系统版本强相关排查时需要对比各Android版本的系统调用白名单差异。4. 实战复盘一次SIGBUS崩溃的完整排查链路4.1 现场崩溃监控平台某天报警有一段时间我们内部维护的某图像处理Demo发了一版更新上线后崩溃率没有大规模飙升但某个特定机型组有密集报警。点开崩溃详情堆栈顶部全是signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0x0000007d2a7c02b8fault addr这个地址尾部直接落在0x...02b8一看就不是自然对齐的地址。backtrace还原后指向的是一个NV12到RGBA的颜色空间转换函数栈帧里的寄存器显示出问题的地方在这个函数内部的一行memcpy附近。当时我的第一反应不是打开代码而是先把tombstone里的maps段翻出来确认这个地址落在哪个so的哪个段里再决定下一步。4.2 从signal到fault addr为什么同一个函数有的设备崩有的不崩这个崩溃在所有模拟器和部分真机上都不复现偏偏在某些真机上密集出现。相同signal相同code但fault addr不同说明问题不是固定地址的踩踏而是某种运行期数据导致的未对齐访问。再往下看backtrace发现崩溃的memcpy前面的数据来源是一个所谓零拷贝的buffer这个buffer是从相机HAL层拿到的帧指针。问题逐渐清晰了不同设备相机的输出buffer首地址对齐策略不一样有的设备保证至少8字节对齐有的只保证4字节而我们的转换函数里直接把buffer首地址硬编码成int类型访问了。可以这样理解一个char*指针表示的地址是0x...02b8如果你直接把它转成unsigned int*来读ARM内核会告诉你对齐不行于是整条链路崩掉。模拟器之所以没事是因为它跑在宿主机上宿主机CPU对未对齐访问的容忍度高而真机ARM上就是零容忍。4.3 修复与验证不要试图说服硬件去适应硬件定位到根因后修复方案其实不复杂在做像素格式转换前先判断输入buffer首地址是否满足16字节对齐如果不满足则做一次按行的memcpy搬运到一块对齐的临时buffer再走原来的高性能路径。代码大致长这样bool isAligned16(const uint8_t* p) { return (reinterpret_castuintptr_t(p) 0xF) 0; } void convertNV12ToRGBA_Safe(const uint8_t* src, size_t stride, uint8_t* dst) { if (!isAligned16(src)) { uint8_t* aligned static_castuint8_t*(aligned_alloc(16, stride * height * 3 / 2)); memcpy(aligned, src, stride * height * 3 / 2); convertNV12ToRGBA_Fast(aligned, stride, dst); free(aligned); return; } convertNV12ToRGBA_Fast(src, stride, dst); }改完在真机上做循环压力测试连续处理了几千帧都没再复现。之后我把这个经验沉淀成了团队的一个代码规约凡是接受外部buffer做解析或转换的native函数入口处必须先校验首地址对齐状态并在必要时做一次廉价拷贝不要赌所有设备的分配策略和你一样。这次排查看似是在解决SIGBUS本质上是在解决为什么信号是这个所以方向是那个的推理过程。signal就是入口但前面分析的所有信息——code、fault addr、maps、backtrace——才是拼图的主体。5. 从signal继续下探高效定位native崩溃的工具与习惯5.1 建立信号量到排查路径的条件反射信号量不是给你看一眼就完的它应该直接决定你下一步去哪。我已经把这套判断方法固化成了条件反射看到SIGSEGV重点查内存访问把fault addr和maps对照看是空指针、野指针、释放后访问还是栈溢出。看到SIGABRT优先展开寻找Abort message找不到再查backtrace里是谁调的abort是堆损坏、异常未捕获还是JNI校验失败。看到SIGBUS先看code。BUS_ADRALN往对齐方向查BUS_ADRERR往mmap映射完整性方向查。看到SIGILL往指令集兼容性和代码段完整性方向查检查设备CPU特性。看到SIGFPE直接去查代码里的整数除法尤其是除数来自外部输入的地方。看到SIGSYS去查系统调用兼容性配合seccomp策略对比。这套判断并不能让你直接写出修复代码但能在你打开IDE之前把可能的问题范围从整个项目压缩到一个很窄的方向。很多人觉得排查难是因为一开始就在几十万行代码里瞎找而正确做法是让日志先把范围框死。5.2 堆栈符号化ndk-stack与llvm-symbolizer的实战用法拿到了原始backtrace不代表拿到了答案因为backtrace里只有偏移地址。要还原成源码行号需要做符号化。经典的工具是ndk-stack。先抓取日志并保存adb logcat -d crash.log然后直接用ndk-stack做符号解析ndk-stack -sym app/build/intermediates/ndk/debug/obj/local/arm64-v8a -dump crash.log-sym指向的是带符号表的so目录。如果你的so没有剥离符号直接用build目录如果发布了release且so被strip过就得用构建时备份的带符号so。新版NDK23及以上更推荐直接用llvm-symbolizer单独解析栈帧llvm-symbolizer --objlibnative-lib.so --functionslinkage --inlines --demangle运行时把tombstone里的pc后面的绝对地址或偏移地址喂进去它会把内联函数链都展开。实际处理时注意保持so和符号版本一致否则还原出来的行号是错位的这个坑我踩过不止一次。5.3 主动触发信号用最小工程建立日志直觉我建议每个做NDK的团队都准备一个实验工程里面故意写几个会崩的函数分别触发SIGSEGV、SIGBUS、SIGFPE然后抓日志看区别。这个工程的价值不在于复现崩溃而在于让你亲眼确认信号、code、fault addr在不同异常下的表现建立起日志直觉。一个简单的触发示例void triggerNullDeref() { volatile int* p nullptr; *p 0x1234; // SIGSEGV, SEGV_MAPERR, fault addr near 0 } void triggerMisalign() { uint8_t buf[64]; uint32_t* p reinterpret_castuint32_t*(buf 1); *p 0xdeadbeef; // SIGBUS on ARM, BUS_ADRALN } void triggerDivByZero() { volatile int a 42; volatile int b 0; volatile int c a / b; // SIGFPE }运行后对比三份日志你会发现signal和code的组合几乎可以直接当作反编译线索。这一步做完以后再看到后端同事复制过来的崩溃片段你的第一反应会快很多。5.4 自己写signal handler时的安全陷阱有人看完这篇文章可能会想那我写一个signal handler捕获信号后自己打日志岂不美哉可以但坑比想象的多。signal handler里必须使用异步信号安全的函数像malloc、new、std::cout、logcat打印这些统统不能碰因为它们在执行过程中可能持有锁而崩溃点可能正巧在同一把锁上于是真相被锁死进程直接卡死或二次崩溃。相对安全的做法是用write()把一个固定buffer写到预打开的fd上。下面是一个尽量安全的handler示例int g_fd -1; void safeHandler(int sig) { const char msg[] native crash occurred\n; write(g_fd, msg, sizeof(msg) - 1); _exit(128 sig); }即便这样_exit之前你还是丢失了正常的tombstone、backtrace等现场信息远不如让系统的debuggerd按默认流程跑完。我个人的实践结论是不要试图在三方SDK之外再造一套崩溃日志系统尽量把signal handler只用于轻量标记把完整的崩溃现场采集交给系统tombstone或者成熟的崩溃监控SDK。还有一个隐藏问题在signal handler里如果再触发一个相同的信号进程会立即终止并且不会产生新的tombstone二次崩溃意味着原始现场被覆盖这是最让人捶桌子的事。所以handler里不要做任何可能引发二次异常的操作包括复杂的字符串格式化。一些实际操作后的体会说句实在话处理native crash这些年我最大的感受是signal本身不负责给你答案它负责给你一个正确的起点。开始觉得SIGSEGV、SIGABRT、SIGBUS这些名字吓人是因为不知道它们背后各代表一类具体问题把这几个信号连同code形成记忆反射之后再看崩溃日志就像看一张导航地图入口在哪、下一步往哪拐心里基本有数。如果你恰好刚接手一个native崩溃占比比较高的项目我建议先别急着改代码花一两天时间把所有历史崩溃按signal分个类再用上面说的路径去逐个核对。这个过程做完你会发现自己对项目的体质了解得比写代码的人还清楚。
半夜两点半手机震动某公有崩溃监控平台推送了一条报警某图像处理Demo在线上设备出现了native crash率上升。我打开详情页第一眼看到的不是堆栈不是机型分布而是一行看起来非常信息密集的日志——signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000000。很多Android开发者到了这一步就卡住了因为平时写Java层代码根本不会直面signal这种东西但native crash排查恰恰是从这一行开始的。这篇内容我会把Android native crash里signal信号量的含义彻底讲透它为什么会出现、每个信号背后对应什么类型的崩溃、看到不同信号该怎么往下查。内容不会只停在信号表背熟的层面还会给出真实的排查链路和工具操作方式希望对正在做NDK开发、音视频处理或者集成了第三方C/C库的朋友有价值。1. 崩溃日志里的signal第一眼就要看懂的那行字1.1 一份典型的native crash日志拆解Android发生native crash时系统通常会在logcat里输出一份简化的tombstone信息并在/data/tombstones或通过崩溃监控SDK汇总一份完整报告。完整报告打开后样貌大概是这样的已脱敏*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** pid: 28412, tid: 28432, name: RenderThread com.example.app signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000000 Cause: null pointer dereference r0 0000000000000000 r1 0000007d5988a0c0 r2 0000000000000004 r3 0000007d5988a0c0 r4 0000000000000000 r5 0000007d5988a0c8 pc 0000007d5988a1a0 sp 0000007d5988a0c0 backtrace: #00 pc 00000000000012c0 /data/app/.../libnative-lib.so (offset 0x12c0) #01 pc 0000000000001480 /data/app/.../libnative-lib.so (Java_com_example_app_NativeLib_processFrame) #02 pc 0000000000007880 /system/lib64/libart.so (art::...)重点看这几处pid/tid/name崩溃发生的进程和线程name直接告诉你崩溃跑在哪个线程比如这里的RenderThread对判断是不是渲染链路问题非常关键。signal 11 (SIGSEGV)本次崩溃的信号。11是信号值SIGSEGV是宏名这两个必须一起看。code 1 (SEGV_MAPERR)同一个信号下的细分原因码。SEGV_MAPERR意思是访问了根本没有映射的地址。fault addr 0x0000000000000000触发异常时的地址。这里是0基本就是空指针读写跑不掉了。backtrace原始栈帧需要用符号化工具还原成函数名和行号。所以读崩溃日志的正确顺序不是直奔backtrace而是先把signal code fault addr这三行连起来看。这三行能直接告诉你进程死在哪一类问题上后面查代码才有方向。1.2 signal、code、fault addr 三者的联动关系signal的值是有限的但同一个signal出现时code往往能给出更精确的切入信息。我整理了Android native crash里常见的信号值和对应codesignal值宏名含义常见细分codeAndroid崩溃中的典型场景4SIGILL非法指令ILL_ILLOPC / ILL_ILLOPN执行了CPU不支持的指令、函数指针跳飞5SIGTRAP陷阱/断点无特殊细分调试器干预、__builtin_trap、某些assert6SIGABRT主动终止无特殊细分abort、堆损坏检测、ART_JNI校验失败7SIGBUS总线错误BUS_ADRALN / BUS_ADRERR未对齐访存、mmap文件被截断后继续访问8SIGFPE算术异常FPE_INTDIV / FPE_INTOVF整数除零、整数溢出10SIGUSR1用户自定义无业务自定义比较少出现在崩溃报告11SIGSEGV段错误SEGV_MAPERR / SEGV_ACCERR空指针、野指针、释放后访问、越界31SIGSYS非法系统调用SYS_SECCOMPseccomp限制下调用非白名单系统调用光看这张表仍然不够还要学会把三个字段放在一起推理。举个例子SIGSEGV SEGV_MAPERR fault addr 0x0十有八九是空指针解引用。SIGSEGV SEGV_ACCERR fault addr 0x...地址是存在的但权限不对典型的是往只读页写入比如往字符串常量区写数据。SIGBUS BUS_ADRALN fault addr 0x...地址在未对齐的边界上ARM设备上特别常见。SIGBUS BUS_ADRERR fault addr 0x...访问了mmap映射范围之外的物理地址常见于文件被截断后还在读映射页。关于fault addr还有一个非常实用的判断技巧如果fault addr和PC寄存器值接近说明进程可能是跳到这个地址执行时炸的比如函数指针被写坏如果PC正常、fault addr是某个数据地址那这就是一次普通的内存读写问题。这个区分能帮你少走很多弯路。日常工程里一份完整tombstone的Cause字段比如null pointer dereference其实是根据signal和code自动生成的提示但这个字段只能当参考最终还是要靠backtrace确认。2. Linux信号机制与Android的适配signal从来不是随便发出来的2.1 信号的三类来源内核异常、主动abort、进程间通知要理解signal必须先想清楚一个问题这个信号到底是谁发出的信号的来源基本可以分成三类。第一类是硬件异常经内核转化。CPU执行指令时发生页错误、对齐检查、除零等异常CPU会触发对应的异常处理流程内核发现这个异常属于某个用户态进程便把这个异常转化为SIGSEGV、SIGBUS、SIGFPE之类的信号发给该进程。这类信号有一个特点它是同步的并且由正在执行的线程当场产生跟当前指令强相关。第二类是用户态代码主动抛出。最常见的例子是调用abort()它会向当前进程发送SIGABRT。为什么代码会主动调abort因为程序内部某处检测到状态已经无法继续比如malloc检测到堆元数据被破坏、C运行时抛出未被捕获的异常后调用std::terminate、Android的ART虚拟机在做JNI校验时发现类型不匹配都会走主动abort这条路。第三类是进程间发送的信号。别的进程通过kill()系统调用给崩溃进程发信号或者用户在shell里执行kill -6 pid手动触发。这种在线上crash里相对少见但一旦出现需要先怀疑是不是有外部监督进程在kill你的App再回头看自己的代码。三类来源对应着完全不同的排查方向如果是硬件异常转信号主要查代码里的内存访问指令如果是主动abort主要查底层库或运行时的校验信息如果是外部信号主要查进程管理和业务守护逻辑。2.2 Android和标准Linux的差异bionic、ART与debuggerdAndroid的native层基于Linux但它的libc是bionic不是glibc这导致崩溃行为有不少差异。bionic的堆分配器比如现代Android上的scudo内置了非常强的完整性检查。如果你在某个线程里把一块buffer越界写穿了破坏到了相邻chunk的元数据下一次分配或释放时分配器会发现异常并主动调用abort。这种崩溃在tombstone里通常会有一行Abort message直接把真正的原因写出来比如heap corruption detected by scudo。所以我一直建议身边做native开发的同事遇到SIGABRT先不要急着看backtrace第一时间展开找Abort message它经常是定位的金钥匙。ART虚拟机也会介入信号处理。当你用JNI从Java调用native函数时如果native代码访问了JNI引用之外的野指针ART的JNI检查可能先于内核汇报错误反过来如果native崩溃发生ART会在崩溃回调里把信号信息翻译给Java层的Thread.setUncaughtExceptionHandler这就是很多崩溃SDK能同时拿到Java和native堆栈的原因。Android上的崩溃收集还有一个关键角色debuggerd。进程收到崩溃信号后系统会唤醒debuggerdAndroid 8.0之后是userdebuggerd由它采集寄存器、加载的so列表、backtrace并写成tombstone文件。这也是为什么我们在logcat里能看到完整的*** *** ***格式日志而不是只有一行signal信息。2.3 同步信号与异步信号同样的信号值完全不同的排查方向很多新手容易忽略一个点同样是SIGABRT可能是当前线程自己abort也可能是别的线程在崩溃检查中abort两者在backtrace上表现出来完全不同。SIGSEGV、SIGBUS、SIGILL、SIGFPE这类由当前指令触发的信号通常是同步信号信号到达的线程就是出问题的线程所以直接沿着该线程的backtrace查就行。SIGABRT、SIGTERM、SIGKILL这类既有主动触发也有外部触发的信号往往是异步的你需要额外注意崩溃线程可能不是元凶线程真正的问题可能发生在另一个线程的检查点。我在工程里遇到过很多次这样的情况SIGABRT的backtrace开头永远是abort - __pthread_kill - raise这组栈再往下才会看到业务帧。很多刚入门的同学看到__pthread_kill就懵了其实这是正常的因为abort本身就是一套固定的系统调用链。真正该看的是业务栈帧里哪一行代码触发了abort以及Abort message里写了什么。3. 高频信号逐个拆SIGSEGV、SIGABRT、SIGBUS、SIGILL、SIGFPE3.1 SIGSEGV空指针、野指针、释放后访问、栈溢出SIGSEGV是native crash里占比最大的信号没有之一。它表示进程访问了一个没有权限或没有映射的内存地址。现实中遇到最多的是几种情况第一种是空指针解引用。fault addr通常接近0x0code是SEGV_MAPERRCrash日志里的Cause常写null pointer dereference。Java层空指针会直接抛NullPointerException但native层不会它就是干净的信号。第二种是野指针和已经释放的栈内存地址。指针变量里存了一个随机垃圾值指向的区域没有映射fault addr往往是某个看起来不太正常的小地址。第三种是典型的use-after-free内存被free之后指针没有置空后续又去读写如果这块地址被回收并重新映射可能报SEGV_MAPERR或SEGV_ACCERR具体取决于分配器怎么处置这块区域。还有一种极其容易忽略的情况是栈溢出。线程栈是有上限的如果递归过深或者栈上开了超大数组线程会顶到栈底以外的未映射区域产生SIGSEGV。这种崩溃的识别特征很有意思fault addr会非常靠近某个映射区域的边界而且在backtrace里你经常能看到连续多帧指向同一个函数典型的递归帧。排查SIGSEGV时我强烈建议把tombstone里附带的maps段打开看一眼把fault addr落到内存地图上它落在堆区栈区某个so的只读段还是完全未映射的虚空落点不同问题性质完全不同。3.2 SIGABRT主动认错的崩溃答案可能写在Abort message里SIGABRT是第二常见的崩溃信号但它和SIGSEGV的本质不同在于极端地说SIGABRT其实是系统在说这个程序已经被判定没救了主动按下终止键而不是踩到地雷。很多C开发者会遇到一种典型情况线程里抛出了异常但外层没有catchC运行时找不到对应的异常处理器于是调用std::terminate()terminate内部再走abort。这种崩溃看起来就像业务代码没有异常保护。另一个高频触发点是bionic加固后的堆检测。比如你用一个指针往堆块之外多写了一个字节scudo分配器很可能在某个mtx上检测到破坏直接abortAbort message里会带有堆损坏的提示。ART虚拟机也会触发SIGABRT。比如你在JNI层调用了GetFieldID但传进去的字段名和Java类里的实际字段对不上或者把jclass误传给某个需要jobject参数的函数ART的CheckJNI机制会输出一条详细的错误信息然后abort。这种崩溃的backtrace通常能直接看到art::JavaVMExt::JniAbort之类的帧。遇到SIGABRT操作顺序应该是先展开找Abort message把这一行文字完整复制出来搜索大部分情况下能直接定位到代码附近的检查点如果找不到Abort message再去看backtrace里的业务栈帧重点找对abort()、__stack_chk_fail、std::terminate、art::*Jni*的调用来源。3.3 SIGBUS与SIGILL对齐与指令集的坑SIGBUS在Android真机上比很多人想象中常见。ARM架构对内存对齐要求严格当你试图通过一个int*去读一个只按2字节对齐的地址时CPU会报总线错误。这种崩溃在把二进制数据反序列化成结构体时最典型从网络或文件里读到一个字节流buffer直接把buffer强转成结构体指针然后访问结构体里的int字段。很多本地产物的buffer恰好是8字节对齐的所以测试时完全正常但另一台设备上buffer首地址只按4字节对齐线上就开始崩。另一种SIGBUS是mmap文件映射后续问题。比如你把一个文件mmap到内存然后另一线程把文件截断了你再去访问映射区域的某个页内核找不到对应的物理页就会发SIGBUS。这类崩溃的code通常是BUS_ADRERRfault addr落在文件映射区域内。解决办法是在访问映射页之前主动校验文件长度同时避免并发截断映射文件。SIGILL则是CPU根本不认识这段指令。常见原因包括二进制so用的是当前设备CPU不支持的扩展指令集比如在老旧设备上跑了带高级SIMD指令的代码、函数指针被写坏后跳到非代码区域执行、以及部分加壳/混淆so在运行期自行修改指令导致解析失败。排查SIGILL时需要把崩溃点附近的几种指令集特性和设备型号列出来做交叉对比经常能发现是某类较老设备专属的崩溃。3.4 SIGFPE与SIGSYS数学异常和系统调用的边界SIGFPE名字里带“浮点”实际最常见的触发却是整数除零。在C/C里直接写int a 100 / 0并不会像Java那样抛异常而是CPU产生算术异常内核转成SIGFPE。代码里如果存在外部传入的除数变量一定要做非零校验。SIGSYS相对少见但一旦遇到就非常让人头疼。它的经典触发场景是进程被seccomp过滤器约束后调用了某个不在白名单里的系统调用。Android系统组件和部分厂商ROM会启用seccomp策略如果你的so为了某些目的直接使用了较新的系统调用而当前设备内核配合的seccomp策略不允许就会直接收到SIGSYS。这种崩溃通常跟特定系统版本强相关排查时需要对比各Android版本的系统调用白名单差异。4. 实战复盘一次SIGBUS崩溃的完整排查链路4.1 现场崩溃监控平台某天报警有一段时间我们内部维护的某图像处理Demo发了一版更新上线后崩溃率没有大规模飙升但某个特定机型组有密集报警。点开崩溃详情堆栈顶部全是signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0x0000007d2a7c02b8fault addr这个地址尾部直接落在0x...02b8一看就不是自然对齐的地址。backtrace还原后指向的是一个NV12到RGBA的颜色空间转换函数栈帧里的寄存器显示出问题的地方在这个函数内部的一行memcpy附近。当时我的第一反应不是打开代码而是先把tombstone里的maps段翻出来确认这个地址落在哪个so的哪个段里再决定下一步。4.2 从signal到fault addr为什么同一个函数有的设备崩有的不崩这个崩溃在所有模拟器和部分真机上都不复现偏偏在某些真机上密集出现。相同signal相同code但fault addr不同说明问题不是固定地址的踩踏而是某种运行期数据导致的未对齐访问。再往下看backtrace发现崩溃的memcpy前面的数据来源是一个所谓零拷贝的buffer这个buffer是从相机HAL层拿到的帧指针。问题逐渐清晰了不同设备相机的输出buffer首地址对齐策略不一样有的设备保证至少8字节对齐有的只保证4字节而我们的转换函数里直接把buffer首地址硬编码成int类型访问了。可以这样理解一个char*指针表示的地址是0x...02b8如果你直接把它转成unsigned int*来读ARM内核会告诉你对齐不行于是整条链路崩掉。模拟器之所以没事是因为它跑在宿主机上宿主机CPU对未对齐访问的容忍度高而真机ARM上就是零容忍。4.3 修复与验证不要试图说服硬件去适应硬件定位到根因后修复方案其实不复杂在做像素格式转换前先判断输入buffer首地址是否满足16字节对齐如果不满足则做一次按行的memcpy搬运到一块对齐的临时buffer再走原来的高性能路径。代码大致长这样bool isAligned16(const uint8_t* p) { return (reinterpret_castuintptr_t(p) 0xF) 0; } void convertNV12ToRGBA_Safe(const uint8_t* src, size_t stride, uint8_t* dst) { if (!isAligned16(src)) { uint8_t* aligned static_castuint8_t*(aligned_alloc(16, stride * height * 3 / 2)); memcpy(aligned, src, stride * height * 3 / 2); convertNV12ToRGBA_Fast(aligned, stride, dst); free(aligned); return; } convertNV12ToRGBA_Fast(src, stride, dst); }改完在真机上做循环压力测试连续处理了几千帧都没再复现。之后我把这个经验沉淀成了团队的一个代码规约凡是接受外部buffer做解析或转换的native函数入口处必须先校验首地址对齐状态并在必要时做一次廉价拷贝不要赌所有设备的分配策略和你一样。这次排查看似是在解决SIGBUS本质上是在解决为什么信号是这个所以方向是那个的推理过程。signal就是入口但前面分析的所有信息——code、fault addr、maps、backtrace——才是拼图的主体。5. 从signal继续下探高效定位native崩溃的工具与习惯5.1 建立信号量到排查路径的条件反射信号量不是给你看一眼就完的它应该直接决定你下一步去哪。我已经把这套判断方法固化成了条件反射看到SIGSEGV重点查内存访问把fault addr和maps对照看是空指针、野指针、释放后访问还是栈溢出。看到SIGABRT优先展开寻找Abort message找不到再查backtrace里是谁调的abort是堆损坏、异常未捕获还是JNI校验失败。看到SIGBUS先看code。BUS_ADRALN往对齐方向查BUS_ADRERR往mmap映射完整性方向查。看到SIGILL往指令集兼容性和代码段完整性方向查检查设备CPU特性。看到SIGFPE直接去查代码里的整数除法尤其是除数来自外部输入的地方。看到SIGSYS去查系统调用兼容性配合seccomp策略对比。这套判断并不能让你直接写出修复代码但能在你打开IDE之前把可能的问题范围从整个项目压缩到一个很窄的方向。很多人觉得排查难是因为一开始就在几十万行代码里瞎找而正确做法是让日志先把范围框死。5.2 堆栈符号化ndk-stack与llvm-symbolizer的实战用法拿到了原始backtrace不代表拿到了答案因为backtrace里只有偏移地址。要还原成源码行号需要做符号化。经典的工具是ndk-stack。先抓取日志并保存adb logcat -d crash.log然后直接用ndk-stack做符号解析ndk-stack -sym app/build/intermediates/ndk/debug/obj/local/arm64-v8a -dump crash.log-sym指向的是带符号表的so目录。如果你的so没有剥离符号直接用build目录如果发布了release且so被strip过就得用构建时备份的带符号so。新版NDK23及以上更推荐直接用llvm-symbolizer单独解析栈帧llvm-symbolizer --objlibnative-lib.so --functionslinkage --inlines --demangle运行时把tombstone里的pc后面的绝对地址或偏移地址喂进去它会把内联函数链都展开。实际处理时注意保持so和符号版本一致否则还原出来的行号是错位的这个坑我踩过不止一次。5.3 主动触发信号用最小工程建立日志直觉我建议每个做NDK的团队都准备一个实验工程里面故意写几个会崩的函数分别触发SIGSEGV、SIGBUS、SIGFPE然后抓日志看区别。这个工程的价值不在于复现崩溃而在于让你亲眼确认信号、code、fault addr在不同异常下的表现建立起日志直觉。一个简单的触发示例void triggerNullDeref() { volatile int* p nullptr; *p 0x1234; // SIGSEGV, SEGV_MAPERR, fault addr near 0 } void triggerMisalign() { uint8_t buf[64]; uint32_t* p reinterpret_castuint32_t*(buf 1); *p 0xdeadbeef; // SIGBUS on ARM, BUS_ADRALN } void triggerDivByZero() { volatile int a 42; volatile int b 0; volatile int c a / b; // SIGFPE }运行后对比三份日志你会发现signal和code的组合几乎可以直接当作反编译线索。这一步做完以后再看到后端同事复制过来的崩溃片段你的第一反应会快很多。5.4 自己写signal handler时的安全陷阱有人看完这篇文章可能会想那我写一个signal handler捕获信号后自己打日志岂不美哉可以但坑比想象的多。signal handler里必须使用异步信号安全的函数像malloc、new、std::cout、logcat打印这些统统不能碰因为它们在执行过程中可能持有锁而崩溃点可能正巧在同一把锁上于是真相被锁死进程直接卡死或二次崩溃。相对安全的做法是用write()把一个固定buffer写到预打开的fd上。下面是一个尽量安全的handler示例int g_fd -1; void safeHandler(int sig) { const char msg[] native crash occurred\n; write(g_fd, msg, sizeof(msg) - 1); _exit(128 sig); }即便这样_exit之前你还是丢失了正常的tombstone、backtrace等现场信息远不如让系统的debuggerd按默认流程跑完。我个人的实践结论是不要试图在三方SDK之外再造一套崩溃日志系统尽量把signal handler只用于轻量标记把完整的崩溃现场采集交给系统tombstone或者成熟的崩溃监控SDK。还有一个隐藏问题在signal handler里如果再触发一个相同的信号进程会立即终止并且不会产生新的tombstone二次崩溃意味着原始现场被覆盖这是最让人捶桌子的事。所以handler里不要做任何可能引发二次异常的操作包括复杂的字符串格式化。一些实际操作后的体会说句实在话处理native crash这些年我最大的感受是signal本身不负责给你答案它负责给你一个正确的起点。开始觉得SIGSEGV、SIGABRT、SIGBUS这些名字吓人是因为不知道它们背后各代表一类具体问题把这几个信号连同code形成记忆反射之后再看崩溃日志就像看一张导航地图入口在哪、下一步往哪拐心里基本有数。如果你恰好刚接手一个native崩溃占比比较高的项目我建议先别急着改代码花一两天时间把所有历史崩溃按signal分个类再用上面说的路径去逐个核对。这个过程做完你会发现自己对项目的体质了解得比写代码的人还清楚。
