今天在公司里遇到一个很奇怪的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元起,快前往官网查看详情吧