今天在公司里遇到一个很奇怪的core dump，初看起来，core dump的code在stl库的hashtable里，完全没有任何头绪，甚至连core dump的原因都一筹莫展。

创新互联建站服务项目包括喀喇沁网站建设、喀喇沁网站制作、喀喇沁网页制作以及喀喇沁网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，喀喇沁网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到喀喇沁省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

白天花了半天的时候看了一下hashtable的implementation，大概知道该去关注那些variable，之后用gdb把core dump加载起来，过了一遍几个重点变量的值，确定了可能是某个singleton的值被correput了，导致原来的class member里的一个unordered_set的underlying的hashtable的值不对了。

经过跟同事反复的讨论，最后我们发现root cause是这样的：

某个同事在头文件A.h里定义了一个singleton：

static A& A::getInstance() {
    static A a;
    return a;
}

然后在某个被称为plugin B的动态库里include了这个头文件，同时在binary C的Main.C里也include了这个头文件。而binary C也同时通过dlopen加载plugin B。

注意这里就出现了问题，此时singleton已经不完全是singleton了。通过nm命令可以看到binary C和plugin B的symbol table里都有A::getInstance()，并且他们在data section里的地址是不同的，此时问题已经很明显了。

进一步观察core dump发生时的behavior，在那个时间点binary C reload了一次plugin B，同事怀疑在unload动态库的时候对这个static变量作了一次析构，而之后重新load plugin B以后，plugin B使用的singleton变量的地址实际还是binary C的，这时候binary C里的static变量已经被析构了，所以造成了ub，同时造成了core dump！

我们通过一个很简单的reproducer去重现了core dump，证实了我们的猜想。

（？code）

你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧

当前名称：C++在头文件中定义singleton出现的问题-创新互联
当前路径：http://scyanting.com/article/dcishe.html