Fedora下BaseX客户端共享库double free错误排查及内存修复

1. 统一编译选项与启用调试 #

• 确认共享库、测试程序与原Eclipse项目的编译选项完全一致：必须都添加-fPIC（共享库编译强制要求）、相同的C++标准（如-std=c++17），且内存分配器逻辑统一（避免混用malloc/free和new/delete）。
• 所有模块编译时添加-g选项，生成带调试信息的二进制文件，方便后续定位问题。

2. 生成并分析core dump #

• 在终端执行ulimit -c unlimited，解除core dump大小限制，再运行测试程序：LD_LIBRARY_PATH=~/lib/lib64 ./libTest，程序崩溃后当前目录会生成core文件。
• 用GDB加载调试：gdb ./libTest core，输入bt命令查看调用栈，直接定位触发double free的代码行。

3. 解决跨模块内存释放冲突 #

• 禁止跨模块交叉释放内存：共享库内分配的内存必须由共享库提供的接口释放，主程序分配的内存由主程序自行处理。
• 调整公共头文件接口：若库返回堆分配对象（如char*、自定义类实例），需配套提供释放函数（如void basex_free_result(char*)），让主程序调用该函数完成释放，而非直接使用free/delete。

4. 排查STL容器跨模块问题 #

• 若共享库向主程序暴露STL容器（如std::string、std::vector），需确保库与主程序使用完全一致的STL版本及编译选项。否则STL容器的内部内存管理逻辑不兼容，会触发内存错误。
• 优化方案：将STL对象封装在共享库内部，仅对外提供C风格或自定义的非STL接口，避免跨模块传递STL容器。

5. 手动排查内存操作逻辑 #

• 检查共享库代码：排查是否存在重复释放同一指针、释放栈内存、使用野指针等情况。
• 关键位置添加日志：在内存分配（如new/malloc）和释放（如delete/free）处打印指针地址，通过日志对比找出重复释放的操作。

6. 使用AddressSanitizer定位错误 #

• 用-fsanitize=address编译共享库和测试程序，例如：

  # 编译共享库
  g++ -g -fsanitize=address -fPIC -shared -o libbasexclient.so basex_client.cpp
  # 编译测试程序
  g++ -g -fsanitize=address -o libTest libTest.cpp -L~/lib/lib64 -lbasexclient
  

• 运行测试程序，AddressSanitizer会直接输出double free的具体位置、调用栈等详细信息，无需依赖core dump。

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