如何排查.so库Bug根因？hook.so拦截JVM调用libc.so.6崩溃求助

首先，你遇到的Aborted (core dumped)伴随SIGSEGV（段错误），本质是内存访问违规——要么是你的hook.so里存在非法内存操作，要么是Hook逻辑破坏了JVM或libc的正常调用流程。结合你提供的hs_err日志片段，先拆解当前崩溃的可能原因，再给你一套通用的.so库Bug排查方案。

针对当前JVM崩溃的核心排查点 #

1. 补全并分析hs_err_pid日志的完整栈信息 #

你只贴了日志开头，一定要看日志里的Current Thread和Stack Trace部分：

Current Thread: #

tid: 0x00007fb3baa8c700 #

nid: 0x27a4 runnable #

java.lang.Thread.State: RUNNABLE #

Stack: [0x00007fb3ba98b000, 0x00007fb3baa8d000], sp=0x00007fb3baa8b9b0, free space=1019k #

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) #

C [hook.so+0x927] your_hook_function+0x27 #

C [libc.so.6+0x12345] malloc+0x45 #

V [libjvm.so+0xabcde] os::malloc(unsigned long, unsigned char)+0xfe #

如果栈里直接指向你的hook.so函数，那问题肯定出在Hook逻辑里；如果是JVM或libc的代码，那大概率是你的Hook破坏了原函数的调用约定或参数传递。

2. 检查Hook函数的调用约定与原型一致性 #

libc的函数遵循系统调用约定（x86_64下是System V AMD64 ABI），如果你的Hook函数原型和原函数不匹配，会直接导致参数传递错误、寄存器破坏：

• 比如Hookmalloc，原型必须是void* malloc(size_t size)，不能写错参数类型；
• 针对可变参数函数（比如printf），必须用va_list正确处理，不能直接硬编码参数；
• 如果是用汇编实现Hook，必须手动保存非易失性寄存器（rbx, rbp, r12-r15），调用原函数后再恢复——JVM依赖这些寄存器的状态，破坏会直接引发崩溃。

3. 验证原libc函数的调用逻辑 #

很多人写Hook时会犯递归调用的错误：比如Hookmalloc后，在Hook函数里又调用了malloc，导致无限递归直到栈溢出。解决方法是：

• 用dlsym(RTLD_NEXT, "malloc")获取原函数指针，确保调用的是真正的libc函数；
• 在Hook函数执行期间，临时禁用Hook（比如用全局变量标记，进入Hook时设置标记，退出时清除，避免递归）。

4. 检查Hook函数的线程安全性 #

JVM是多线程环境，libc的大部分函数都是线程安全的，但你的Hook函数如果使用了全局变量、未加锁的共享资源，会引发竞态条件，导致内存 corruption，最终触发SIGSEGV。

通用.so库Bug排查工具与方法 #

1. 利用Core Dump定位崩溃点 #

首先确保系统允许生成core文件：

ulimit -c unlimited

重新运行触发崩溃的命令，生成core.<pid>文件后，用gdb分析：

gdb $(which java) core.635

在gdb里执行：

• bt：查看完整栈跟踪，直接定位到崩溃的代码行；
• frame <n>：切换到指定栈帧，查看局部变量和寄存器状态；
• info registers：检查寄存器值，看是否有异常（比如指针指向0地址）。

2. 给Hook库添加调试信息 #

编译hook.so时加上-g参数，保留源代码调试信息，这样gdb里能直接看到崩溃对应的源代码行，而不是一堆内存地址：

gcc -g -shared -fPIC hook.c -o hook.so -ldl

3. 用strace/ltrace跟踪调用流程 #

• strace：跟踪系统调用，看崩溃前是否有异常的内存访问、文件操作：

  strace -f -o strace.log java -jar your_app.jar
  

  搜索SIGSEGV前后的调用，看是否有mmap失败、访问非法地址的情况。
• ltrace：跟踪库函数调用，看你的Hook函数和原libc函数的参数、返回值是否正常：

  ltrace -f -o ltrace.log java -jar your_app.jar
  

  重点看Hook函数的输入参数是否符合预期，原函数的返回值是否被正确处理。

4. 逐步简化Hook逻辑定位问题 #

先写一个“空Hook”——只调用原函数，不做任何自定义逻辑：

#include <dlfcn.h>
#include <stdlib.h>

void* malloc(size_t size) {
    static void* (*original_malloc)(size_t) = NULL;
    if (!original_malloc) {
        original_malloc = dlsym(RTLD_NEXT, "malloc");
    }
    return original_malloc(size);
}

如果这个空Hook运行正常，说明问题出在你添加的自定义逻辑里；再逐步添加代码，每加一部分就测试一次，直到触发崩溃，就能定位到具体的bug点。

5. 用Valgrind检测内存问题 #

Valgrind可以检测非法内存访问、内存泄漏等问题，虽然运行JVM会比较慢，但对于排查内存类bug非常有效：

valgrind --leak-check=full --track-origins=yes java -jar your_app.jar

它会直接指出你代码中哪里出现了空指针解引用、数组越界等问题。

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