注意：这个答案是由一位希望保持匿名但希望有所帮助的同事提供给我的。我没有解决这个问题。
我在工作中遇到了类似症状的问题。
这个答案概述了我如何解决这个问题。
大多数/所有这些信息都可以在互联网上的其他地方找到，但我找不到像这样整合的信息，而且，作为一个不“知情”的人，一开始对我来说并不是很明显（而且只是现在对我来说更明显了）。
如果我有任何错误，请提前道歉......
关于我正在使用的机器的一些信息：
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.9 (Santiago)
$ g++ --version
g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
...
$ /lib64/libc.so.6
GNU C Library stable release version 2.12, by Roland McGrath et al.
...
$ uname -srm
Linux 2.6.32-696.6.3.el6.x86_64 x86_64
一个极简的工作示例：
common.h:
#include <string>
struct Common {
static const std::string s;
};
common.cpp:
#include "common.h"
const std::string Common::s("common");
main.cpp:
#include <iostream>
#include "common.h"
int main(void) {
std::cout << Common::s << std::endl;
return 0;
}
构建（调试符号有帮助，但可能不是绝对必要的）：
$ g++ -g -shared -fPIC common.cpp -o libone.so
$ g++ -g -shared -fPIC common.cpp -o libtwo.so
$ g++ -g main.cpp -L. -lone -ltwo -o main
运行（注意它可能运行良好...）：
$ # turn on core dumping
$ ./main
common
*** glibc detected *** ./main: double free or corruption (...): 0x... ***
======= Backtrace: =========
/lib64/libc.so.6[0x...]
/lib64/libc.so.6[0x...]
/usr/lib64/libstdc++.so.6(_ZNSsD1Ev+0x...)[0x...]
/lib64/libc.so.6(__cxa_finalize+0x...)[0x...]
libtwo.so(+0x...)[0x...]
======= Memory map: ========
...
Aborted (core dumped)
$
检查核心：
$ gdb -c core.<pid> -e main
...
Core was generated by `./main'.
Program terminated with signal 6, Aborted.
#0 0x... in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x... in raise () from /lib64/libc.so.6
#1 0x... in abort () from /lib64/libc.so.6
#2 0x... in __libc_message () from /lib64/libc.so.6
#3 0x... in malloc_printerr () from /lib64/libc.so.6
#4 0x... in _int_free () from /lib64/libc.so.6
#5 0x... in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string () from /usr/lib64/libstdc++.so.6
#6 0x... in __cxa_finalize () from /lib64/libc.so.6
#7 0x... in __do_global_dtors_aux () from /libtwo.so
#8 0x... in ?? ()
据我所知，一些说明：
在启动时，在 main 之前，静态析构函数在静态初始化时注册到 __cxa_atexit（或类似）。
然后，在“常规”退出之前，程序通过并以相反的顺序调用已注册的析构函数。
__cxa_atexit 接受 3 个参数。
第一个是函数（例如 dtor 类）。
第 2 个是第一个 arg 中函数的 arg（例如 std::string*）。
第三个参数我会忽略...
在 Linux 上的 x86-64（我正在开发的平台）上，第一个、第二个参数分别在 %rdi、%rsi 中传递。
这个想法是打破__cxa_atexit，记录寄存器中的内容，并在程序启动完成后查找重复项。
一些与寄存器内容相关的上下文会很有用。
gdb 回溯看起来像这样：
(gdb) bt
#0 0x... in __cxa_atexit_internal () from /lib64/libc.so.6
#1 0x... in __static_initialization_and_destruction_0 (...) at common.cpp:2
#2 0x... in global constructors keyed to _ZN6Common1sE () at common.cpp:3
#3 0x... in __do_global_ctors_aux () from libone.so
#4 0x... in _init () from libone.so
...
帧 3/4 让您查看要查看的二进制文件（例如，用于反汇编）。
框架 2 让您大致了解静态与哪个源代码块相关联。
框架 1 让您在适当的二进制文件中查找。
在为第 1 帧列出的指令之前的几条指令，您应该会看到哪个地址被加载到 %rsi。
$ gdb --args ./main
...
(gdb) b __cxa_atexit
Breakpoint 1 at 0x...
(gdb) comm
...
>silent
>printf "$rdi %p $rsi %p\n", $rdi, $rsi
>bt 4
>c
>end
(gdb) set pag off
(gdb) set log redirect on
(gdb) set log file __cxa_atexit.txt
(gdb) set log on
Redirecting output to __cxa_atexit.txt.
(gdb) start
(gdb) set log off
Done logging to __cxa_atexit.txt.
(gdb)
请注意，上面的页面/日志设置是可选的。
在这个例子中差别不大，但在我正在使用的“实际”程序中，__cxa_atexit 断点被到达数千次（并且花了几分钟时间才到达 main 的临时断点）。
在输出中查找重复的寄存器行：
grep "^\$rdi" __cxa_atexit.txt | sort | uniq -d
我检查了%rdi 中的地址，感觉良好：
(gdb) x/i 0x...
0x... <_ZNSsD2Ev>: ...
$ c++filt _ZNSsD2Ev
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
或者，使用 gdb 的 i shared 或 i proc map 列表获取偏移量并在适当的二进制文件上使用反汇编程序（不要忘记 offset your offset if needed）。
相关的回溯看起来像这样：
#0 0x... in __cxa_atexit_internal () from /lib64/libc.so.6
#1 0x... in __static_initialization_and_destruction_0 (...) at common.cpp:2
#2 0x... in global constructors keyed to common.cpp(void) () at common.cpp:2
#3 0x... in __do_global_ctors_aux () from libone.so
如果您查看第 3 帧中列出的二进制文件，在第 1 帧中列出的指令之前的几条指令中，您应该会看到在调用 __cxa_atexit 之前加载到 %rsi 的内容。
在这个例子中，objdump 用“绝对偏移量”和_ZN6Common1sE@@Base-0x80 对我进行注释。
“绝对偏移量”应与 readelf -rW 输出的“偏移量”列下列出的相应符号相匹配。
第 1 帧的源代码行列表告诉您哪个静态正在“重复”，您可以跟踪回溯以查看它是如何包含在两个不同的二进制文件中的，将其与构建二进制文件的方式进行比较等。
如果您在构建时没有调试符号，您将无法获得源代码行列表，并且您可能需要进行一些反汇编才能确定要查看源代码的哪个位置。
在开始时，我列出了一些机器信息。
这是我可以访问的另一台机器：
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.4 (Tikanga)
$ g++ --version
g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46)
...
$ /lib64/libc.so.6
GNU C Library stable release version 2.5, by Roland McGrath et al.
...
$ uname -srm
Linux 2.6.18-164.el5 x86_64
上面的大纲在这台机器上构建时不起作用，因为不是用__cxa_atexit注册dtor，而是用__tcf_0、__tcf_1等函数包装dtor。在__cxa_atexit注册。
所以你可能有多个（可能略有不同？）__tcf_* 破坏相同静态的函数。
如果您想在程序启动时捕捉到这一点，您可能需要进行一些程序化（反）汇编检查（我不知道该怎么做）。
您可以尝试在程序关闭时捕捉到这一点，中断对~string、free、_int_free 等的调用，将第一个参数与之前的第一个参数进行比较，然后将第一个参数保存在某处以供将来比较（gdb/python？ ）。
或者，您可以进行一些慷慨的“常规”日志记录并寻找双重免费的事后分析。
更改似乎已在 gcc-4.3.0 中进行。
见gcc-g++-4.3.0.tar.{gz,bz2}，文件gcc/cp/decl.c，函数start_cleanup_fn，register_dtor_fn。
ChangeLog sn-p：
2007-05-31 马克·米切尔
* decl.c (get_atexit_fn_ptr_type)：新函数。
(get_atexit_node)：使用它。
(start_cleanup_fn)：同样。
(register_dtor_fn)：使用对象的析构函数，而不是a
尽可能单独的清理功能。
...