std::unordered_map编译正常运行段错误，求问题原因排查

你遇到的这个问题其实是CentOS 7搭配GCC 4.8.5的一个经典坑——看起来代码完全没问题，但就是运行时崩溃，栈跟踪还指向标准库内部的memset调用，这大概率是GCC 4.8.x版本libstdc++的老bug导致的。

问题根源拆解 #

从你给出的栈跟踪来看，崩溃发生在std::_Hashtable初始化时调用_M_allocate_buckets分配桶数组的环节，具体是memset写入了非法内存。在GCC 4.8.5的libstdc++实现中，unordered_map默认构造会预分配11个桶的数组，而这个过程中存在一个边界处理的bug，在CentOS 7的glibc 2.17环境下会触发非法内存访问。

简单来说，就是标准库内部在初始化桶数组时，传递给memset的参数有问题，导致写了不该写的内存区域，直接触发core dump。

可行的修复方案 #

这里有几个快速解决的办法，按成本从低到高排序：

1. 显式指定初始桶数为0 #

修改unordered_map的构造，强制初始桶数为0，这样就会跳过预分配桶数组的逻辑，避开bug：

std::unordered_map<int,int> hMap(0);

这种改动最小，不需要调整编译环境，适合快速验证。

2. 升级编译器版本 #

CentOS 7可以通过devtoolset安装高版本的GCC（比如8.x），新版本的libstdc++已经修复了这个bug：

# 先安装devtoolset仓库
yum install centos-release-scl
# 安装GCC 8
yum install devtoolset-8-gcc-c++
# 激活高版本编译器环境
scl enable devtoolset-8 bash

之后用新编译器重新编译你的代码，问题就会消失。

3. 检查库依赖兼容性 #

如果不能升级编译器，可以检查程序依赖的库是否有版本冲突。用ldd命令查看程序链接的库：

ldd file

确保libstdc++.so.6和libc.so.6是系统默认的版本，没有被其他第三方库覆盖（比如某些软件自带的高版本libstdc++）。如果有冲突，可以调整环境变量LD_LIBRARY_PATH来优先使用系统库。

验证方法 #

修改代码或调整编译环境后，重新编译运行：

g++ -g -Wall -Werror -std=c++11 -o file file.cpp
./file

正常情况下应该不会再出现core dump了。

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