@codehz ABI 兼容性应该没问题。那个 so 也是我自己编译的，同一系统同样环境。

再说能提示下，怎么检查 ABI 兼容性问题吗？

@wwqgtxx 能简化复现的 bug，不会贴到这里麻烦网友们。

@GeruzoniAnsasu 我多挂载的 so 也是我写的，里面很简单。唯一有问题的，可能在这个 so 也链接 boost circular_buffer 以及我那个类 T 的实现。

现在看来可能是 circular_buffer 的 allocate/deallocate 可能有问题。

@wutiantong 在扇贝 C++写得多不？

我上面写的有一定简化。

原始对象其实是一个 T，里面有两个成员都是 vector of cirular_buffer of int。

我 new 和 delete 的都是 T。

@willm 重载是不可能的，我没写过这么底层的东西，要么就是 boost 里面的实现有重载。

我怀疑跟 runtime link 有关系。

我就喜欢在 C++里用 printf。std::cout 又丑又难用。

std::cout 号称更安全一点，但只要自己注意点，printf 也没啥，再说现在编译器也能识别出大部分不安全的情况。

@lcdtyph so 文件是 dlopen 打开的，不是编译时链接。链接时只链接了.a 文件。

现在看 dlopen 的 runtime link 有些难以琢磨的东西。

@lcdtyph 你是最接近答案的人 :)

@lcdtyph 我已经解决了，把那些 static 成员标记为 hidden 即可。

@lcdtyph 这不行的。不链编译通不过。

找到一模一样的问题： https://stackoverflow.com/questions/2631918/main-program-and-shared-library-initializes-same-static-variable-in-static-ini

@hitmanx 我没加这个。不过我试了下加这个编译参数，还是会运行出错。

我用 nm 命令检查了符号，发现原始没出问题的代码，exe 程序里没有`Token`类的实现，所有 so 文件在运行时都使用各自文件里的实现。

但出问题的代码里，exe 程序里有 Token 类的实现，so 文件在运行时直接用了主程序里的实现。

其中 so 文件我没有重新编译过，所以出问题是发现在运行而不是编译时的函数链接上。

@geelaw Token 只是其中一个类，这里面其实有很多东西，甚至有好几个.a，不太方便都做成.so 。再说用.so 就不能链接内联优化了。

我用 boost::stacktrace 把静态变量的初始化和析构的 stack 都打了出来。发现了问题。

原始没出问题的代码：会有多次初始化和析构，但初始化和析构都用的是各自 dll 里面的代码。

出问题的代码：有多次初始化和析构，但初始化和析构都用的是 exe 程序里面的代码。

现在看，问题主要出现在上面链接的问题。不知道为什么，出问题的程序中，dll 在调用函数时，没用自己的实现，都用的 exe 主程序的实现。（ dll 和 exe 在变异时都链接了 token.a，因此都包含了 Token 类的实现）。

我把这个类静态成员`static const std::vector<std::string>`换成一个自定义的`statc const StaticMember`，然后在`StaticMember`的初始化和析构函数里打印出 log，包含 StaticMember 所在的地址(std::cout << (void*)this)。

然后发现一个神奇的现象，它进行了 4 次初始化和多次析构！并且地址是同一个地址。

```
init, addr:0x8e77a8
init, addr:0x8e77a8
init, addr:0x8e77a8
init, addr:0x8e77a8
deinit, addr:0x8e77a8
deinit, addr:0x8e77a8
```

我的程序结构大约这样的：1 个`exe`文件通过`dlopen`打开了若干个`so`文件，这些 so 文件都链接了`Token`类。这个`Token`类就是包含这个出错的静态成员的类。在编译时，我先把`Token`编译成了`token.a`，然后`exe`和这些`so`文件链接时都链接了`token.a`。

另外，我这个程序以前是能跑的，但只要加一行很简单的代码（这行代码与引起问题的类完全无关），就会导致上面的问题。我才加的这一行代码可能引起了链接程序的一些变化。

我试图简化程序，但还没复现出同样的结果。

@geelaw @hitmanx @zmj1316

@zmj1316 拿 c_str 去 free 不太可能，这个变量里面保存的是字符常量。可能是删除或修改别的导致堆内存损害。

@geelaw 这是一个超大型程序，里面有好几个 so 文件。就这个问题而言，我不确定有 minimal reproduction。这种在`_exit`时出现问题的情况我还是第一次遇到，`gdb`里显示的代码都不是我的代码。

错误类型就是典型的 core dump。

我也感觉是 double free 或者类似的问题。但我用 valgrind 没检查出来。在这里想问问可能是什么原因，以及用什么工具可以检查到这个错误。

@zmj1316 类的 static 变量应该放在单独的内存位置，其析构是程序在结束时自动析构的。我没听说可以主动析构。

写坏这个我就不清楚了，不知道用什么东西可以查出来。我用 valgrind 也是到上面显示的地方才出错，前面没有提示 double free 之类的错误。

汇报一下最后的方案。

主题是没办法替换的，因为原主题已经集成了一些东西。

替换 js 文件之前就试过，没成功，而且替换之后每次升级就需要重新操作，太麻烦。

后来是自己写了一个简单的 js 文件，不用索引，直接强搜所有文档。几十个文档，也瞬间就能搜完。