大数据框架需求背景在鲲鹏上进行spark性能测试（使用velox加速），目前已在arm机器上完成编译。生成gluten-package-1.3.0.jar文件，该JAR包中包含 libgluten.so、libvelox.so 等关键动态库文件，re2、folly 等相关依赖已通过静态库（.a 文件）的方式链接至libvelox.so中。相关配置软件版本 JDK bisheng-jdk1.8.0_412 GCC 10.3.1 问题描述使用编译好的jar包运行local模式的spark-sql出现coredump现象,无hs_err_pid.log日志、core文件生成 spark-sql运行有结果输出，即获得了相关的查询结果，但终端日志出现以下错误free(): double free detected in tcache 2，猜测是执行完成后重复释放资源导致，或者是在so卸载的过程中，内存管理上存在问题。 hs_err_pid.log日志：这是 JVM 在崩溃时自动生成的一个文本文件，记录报错的堆栈及寄存器等信息。 core文件：是操作系统层面的产物，如果配置了ulimit -c unlimited 命令来开启并取消 core 文件的大小限制，当程序崩溃时会报错完整内存映像。分析过程 1、指定本地单线程模式运行在启动命令中指定1 个工作线程（CPU 核心），定位是否为多线程同步执行导致的资源重复释放，指定后依旧出现coredump现象，报错无变化。 2、关闭 jemalloc 线程缓存（tcache）报错显示为double free在tcache 2中，因此在启动命令中加入以下jvm参数关闭tcache，运行后后依旧出现coredump现象，报错无变化。 --conf spark.driverEnv.MALLOC_CONF=tcache:false --conf spark.executorEnv.MALLOC_CONF=tcache:false 3、编译添加asan ASAN asan是Google开发的一款基于编译器的内存错误检测工具，主要用于在开发测试阶段精准捕捉C/C++程序中隐蔽的内存问题，能够有效检测堆/栈/全局变量的缓冲区溢出、释放后使用（Use-After-Free）、双重释放以及内存泄漏等常见致命错误。简单用例：编译运行得到以下结果：使用以下编译参数：再次运行得到以下结果：编译参数补充 ASAN 相关配置。开启 ASAN 后，期望程序在发生内存非法操作时立即崩溃，并打印相关的日志信息进行问题定位。但实际运行时仍出现 coredump，报错信息与未开启 ASAN 时一致，且未生成 core 文件。后续复盘过程发现我们修改的是Velox脚本中配置的参数，但x86环境的流水线编译是读取MakeFile文件进行编译，因此当时ASAN修改未生效。 4、使用jemlloc替换系统malloc 系统malloc指的是glibc ptmalloc，用于进行内存的分配和释放（malloc/free等接口）通过LD_PROLOAD强制替换后，jemalloc 接管了这些调用，由于实现原理的不同，替换malloc实现后有core文件生成，同时生成了hs_err_pid.log日志，但是生成的core没有堆栈符号信息。 --conf spark.driverEnv.LD_PRELOAD=/tmp/omni/gluten-omni/lib/libjemalloc.so core文件信息如下： hs_err_pid.log日志信息如下： hs_err_pid.log 日志未捕获有效异常信息，借助 gdb 分析 core 文件，仅能看到异常调用栈涉及 folly、fmt 相关函数，判定该类调用栈并非问题根因，仅为故障触发时的现场表现，因缺少完整详细堆栈，无法精准定位根源。后续排查发现，实际运行环境采用 OpenJDK，而编译环境使用毕昇 JDK，二者 JDK 版本不一致。 5、切换编译环境JDK版本切换编译环境的 JDK 版本为 OpenJDK，重新运行程序后通过 gdb 分析 core 文件，得到了不同的堆栈信息，最终定位到程序崩溃发生在 re2 的析构过程中。 core文件信息如下： hs_err_pid.log日志信息如下： 6、double free check 打印 re2的析构函数本身是没有问题的，正常的释放了资源，double free表示当前资源被释放了两次，因此我们重写 free 方法，通过哈希表记录已释放的内存地址；若检测到重复释放同一地址，则捕获调用栈。将实现编译为 so 文件后，通过 LD_PRELOAD 方式注入程序，运行过程中进行调试，打印信息如下：可以看到最后一次double free释放出现在VeloxMemory，通过 addr2line -e libvelox.so 0x4fb0fc8 分析发现该库不包含符号信息，因此无法定位到具体的报错代码行。注释掉VeloxMemory的资源释放后问题依旧存在。因此当前方法无法正确定位到报错点，后续复盘也发现重写的free方法实现也有问题，在高并发大数据量的情况下，哈希表很容易造成冲突，导致统计的重复释放不准确。 7、重写re2析构函数无法定位出来到底是什么地方释放了RE2对象导致RE2自己析构时重复释放了，因此这里直接注释RE2析构函数里的实现看是否可以规避，并添加日志打印 RE2::~RE2() { std::cout << "in the ~RE2" << std::endl; /* if (group_names_ != empty_group_names()) delete group_names_; if (named_groups_ != empty_named_groups()) delete named_groups_; delete rprog_; delete prog_; if (error_arg_ != empty_string()) delete error_arg_; if (error_ != empty_string()) delete error_; if (suffix_regexp_) suffix_regexp_->Decref(); if (entire_regexp_) entire_regexp_->Decref(); delete pattern_; */ } 重新编译后发现运行过程并没有打印相应的日志，说明运行过程并没有走进这个实现里，但是core文件显示的堆栈在RE2::~RE2时，因为怀疑编译环境是不是有其他的libre2.a文件，排除过后发现环境并没有。这里不直接重写RE2::~RE2的析构函数然后通过 LD_PRELOAD 方式注入重写的原因是：LD_PRELOAD 是一个运行时的概念，它影响的是程序动态链接阶段的行为，即程序运行过程中去加载的so文件。而实际运行环境的re2是通过静态库（.a 文件）在编译链接阶段就已经被整合进libvelox.so了，libvelox.so内部对这类函数的调用，在编译时就已经被转换为对内部固定地址的跳转或调用指令。 8、更换re2版本对比vcpkg依赖包版本信息后发现当前编译的re2版本与实际运行环境的不一致，因此初步怀疑上层代码可能依赖了特定版本接口，从而引发重复释放问题。将 re2 更换为与实际运行环境一致的版本并重新编译后，问题得到解决。但对比两个re2版本的代码实现发现没有大模块上的修改，整体处理逻辑是保持一致的，因此我们回退到了初始re2版本，重编后问题也修复了，因此可以判定是之前编译的re2有问题。两次编译的差别在于第一次编译使用的是velox自带的组件编译脚本，第二次编译则是下载源码后手动编译，编译参数保持一致。对比之前编译的两次re2编译产物，发现第一次编译的re2.h使用的是之前系统残留的/usr/local/include/re2.h，而第二次编译的re2.h使用的是re2源码自带的re2.h文件，两者存在差异，删除/usr/local/include/re2.h后重编re2后问题也修复了。回溯Velox编译脚本发现配置了CPLUS_INCLUDE_PATH环境变量，修改了头文件的搜索路径，导致查找到了错误的头文件。 9、总结复盘 a、一般程序都是通过so的方式加载相关的依赖，便于运行过程中替换和问题定位，但缺点就是在集群模式下，每一个节点都需要保证加载一样的so文件，缺点是如果某一个节点的so文件不正确或缺少也需要每个节点排查；实际运行环境采用加载.a的方式，可以快速部署到不同的集群上，不需要同步上传累赘的组件so，并且能报错每个节点使用的版本一致，缺点是定位麻烦，每次修改都需要重新构建编译。 b、编译过程需要注意环境变量配置，避免cc文件和h文件不匹配，后续运行过程也有类似的错误，libevent编译链接到了新版本的folly，但是velox编译链接到了比较老版本的folly，导致velox运行过程中使用是int32类型的folly成员变量，但是libevent使用的是int16类型的folly成员变量，导致变量传递时libevent的成员变量的前面16字节丢失，最后导致变量值错误。