零初始化超大动态数组却持续出现非零值的异常问题求助

算力阿峰

2026-4-7

各位开发者朋友，我最近碰到一个特别诡异的系统问题，折腾了好久都没搞明白，特意来求助大家！

先贴出我的代码：

#include <cstdint>
#include <iostream>

constexpr size_t N = 1l<<31;

int main() {
    auto buf = new int64_t[N]{}; // value-initialization zeroes the array
    for (size_t i=0; i<N;i++) {
        if (buf[i]!=0) {
            std::cout << "buf[" << i << "]=" << buf[i] << std::endl;
            break;
        }
    }
    delete[] buf;
}

我用g++ -O3编译这段代码，GCC版本是13.3.0（Ubuntu 13.3.0-6ubuntu2~24.04），每次运行都会输出类似buf[x]=131072的结果——其中x是每次随机变化的索引，偶尔也会出现2^18（256384）这个值。因为这些数都是2的幂次，我怀疑是不是OS内存分页的问题？或者是我的DRAM有硬件故障？也有可能是GCC对超大数组的初始化有什么隐藏限制？

下面是我梳理的几个可能的方向，也给大家一些排查建议：

先算清楚数组的实际大小： N=2^31个int64_t元素，每个元素占8字节，总大小是16GB！这已经远远超过大多数普通机器的物理内存，系统必然会依赖交换分区（swap）来支撑这么大的内存分配。正常来说，new T[N]{}的值初始化要求所有元素为零，但Linux系统为了高效，会用**写时复制（Copy-On-Write）**的方式：一开始给你映射到一个全局的全零共享页，只有当你对页进行写入操作时，才会分配实际的物理页并清零。但这里你是读取操作，按道理触发页错误后，OS应该给你分配清零后的页才对，出现非零值就很反常。
交换分区的残留数据？ 会不会是swap分区里残留了之前进程的旧数据，OS在换入内存页的时候没有正确清零？不过按照系统安全规范，用户进程分配的内存不管来自物理内存还是swap，都应该是清零后再交付的，避免数据泄露，这个可能性理论上很低，但可以检查一下swap的状态，比如用swapoff -a && swapon -a清空swap后再测试。
硬件内存故障？ 比如DRAM的某个固定位卡住了？不过每次出现的索引是随机的，值又是刚好2的幂次，硬件故障一般会导致固定bit位出错（比如某一位始终为1），表现出来的值应该是固定bit组合，而不是这种规律的幂次，所以这个可能性相对较小，但可以用memtest86+之类的工具检测一下内存。
GCC优化的潜在问题？ 虽然C++标准明确要求new T[N]{}是值初始化，但在O3的高优化级别下，会不会有编译器的特殊处理？比如编译器认为这么大的数组初始化开销太大，偷偷改成了默认初始化？你可以试试禁用部分优化，比如用g++ -O0编译，或者添加-fno-optimize-sibling-calls等参数，看看问题是否消失。
内存分配的过度提交？ Linux默认允许内存过度提交（overcommit），也就是允许进程分配超过物理内存+swap的空间，但实际访问时才分配。如果你的swap空间不足，可能会触发OOM killer，但你的程序没被杀死反而出现非零值，这也不符合预期，但可以用sysctl vm.overcommit_memory查看当前的过度提交设置，改成2（严格模式）试试，看是否会直接分配失败。

另外还有几个排查小技巧：

把N改小，比如改成2^30（8GB），看看问题是否还会出现，缩小问题范围；

替换new为malloc+memset，手动清零内存，对比结果：

auto buf = static_cast<int64_t*>(malloc(N * sizeof(int64_t)));
memset(buf, 0, N * sizeof(int64_t));

查看系统日志，比如dmesg里有没有内存页错误、ECC错误或者OOM相关的日志；
换用clang编译器编译，看看是否能复现问题，排除GCC特有的bug。

有没有大佬碰到过类似的问题？或者有其他思路可以指点一下？

内容来源于stack exchange