Android中SIGSEGV与其他信号异常行为差异的原因及处理方案

1. 为何仅SIGSEGV出现JNI无效jobject错误？ #

核心原因是两种信号触发时进程的内存损坏程度完全不同：

• SIGFPE（算术异常，如除零）属于逻辑错误，进程的内存空间（包括JVM维护的JNI对象引用表、线程的JNIEnv结构）并未被破坏，此时调用JNI/Java代码侥幸能正常执行；
• SIGSEGV（段错误）是进程访问了非法内存地址，大概率已经破坏了JVM的内部数据结构——比如JNIEnv指针失效、jobject对应的内存块已被覆盖或释放，这时候再调用Kotlin/Java方法，JNI层的有效性检测直接抛出无效jobject错误，导致进程二次崩溃。

另外要注意：信号处理函数本身要求调用异步安全的函数，而JNI调用、Java方法调用都属于非异步安全操作，SIGFPE只是没触发更严重的内存损坏，这种成功是不可靠的，本质上属于未暴露的风险。

2. 解决方法 #

可以从以下几个方向重构你的异常处理逻辑，彻底避开JNI环境损坏的问题：

• 信号处理器中只做异步安全操作，通过系统命令启动独立进程Activity：
  在信号处理函数中，直接调用system()执行Android的am start命令启动异常提示Activity，完全绕过JNI。示例代码（Native层）：

  system("am start -n com.your.package/.CrashPromptActivity --user 0");
  

  这种方式不需要依赖任何JNI对象，直接通过系统服务启动Activity，不受原进程JNI环境损坏的影响。
• 通过fork子进程处理后续逻辑：
  在信号处理器中fork一个子进程，子进程中执行启动Activity的操作（同样用am start，不要用JNI），父进程直接调用默认信号处理器退出。fork后的子进程拥有独立的内存空间，不会受父进程内存损坏的影响。
• 改用独立守护进程监控主进程：
  单独启动一个轻量的守护进程，通过waitpid()监控主进程的状态，当主进程因SIGSEGV崩溃时，由守护进程启动异常提示Activity。这种方式完全脱离主进程的崩溃现场，最稳定可靠。

3. 若无法直接在信号处理器中启动Activity，如何有效处理SIGSEGV？ #

即使不能在崩溃时实时启动Activity，也可以实现有效的SIGSEGV处理：

• 收集崩溃现场信息：在信号处理器中，用异步安全的函数（如backtrace()、backtrace_symbols_fd()）收集堆栈回溯、寄存器状态等崩溃信息，写入到本地文件中；
• 正常退出进程：调用默认信号处理器让进程自然退出；
• 下次启动时提示用户：应用下次启动时，读取保存的崩溃日志，弹出提示告知用户崩溃情况，甚至提供日志上传功能。

这种方式虽然不能在崩溃瞬间弹出Activity，但能完整保留崩溃信息，且不会导致进程反复崩溃，是生产环境中更稳妥的方案。

内容的提问来源于stack exchange，提问作者Wolfie