C语言free释放malloc二维数组内存未生效导致二次调用崩溃

问题由两层因素共同导致：代码本身存在内存分配计算错误，叠加WSL1的内存模拟层缺陷，最终出现free不生效、二次调用崩溃的现象。

1. 第一级指针数组的分配大小计算错误 #

你定义的megaarray是int**类型，作用是存储循环里分配的所有一级int数组指针，实际需要存储的指针总数是x * count个（和你循环遍历的上限一致），每个指针的大小为sizeof(int*)，因此第一级malloc的正确写法应该是：

megaarray = (int**)malloc( (size_t)x * count * sizeof(int*) );

你当前的代码在计算大小时多乘了一个y参数，相当于申请了x*y*count个int*的存储空间，在你给出的参数下（x=3200、y=4200、count=1000），这块内存的大小约为107GB，远大于你实际需要的25MB左右的指针存储空间。

2. 触发WSL1的mmap实现缺陷 #

glibc的malloc逻辑中，大于128KB（默认mmap阈值）的内存申请会直接调用mmap申请匿名私有映射，不走常规堆块分配流程。你第一级申请的107GB内存会直接走mmap路径，后续循环申请的320万个16.8KB的int数组，也会在堆上产生百万级的小块内存元数据。
而WSL1并非原生Linux内核，是通过翻译Linux系统调用到Windows内核API实现的兼容层，它的内存子系统存在两个长期未修复的已知问题：

• 大段mmap映射在调用munmap（对应free大内存块的操作）时，不会正确通知Windows内核释放预留的虚拟地址段和物理内存页，表现为free后Vmmem进程内存占用完全不下降
• 百万级小内存块的分配释放会损坏WSL1模拟层维护的内存元数据，导致后续free操作无法正确匹配内存块的归属，直接出现内存泄漏

第一次调用函数时，WSL1还能挤出足够的虚拟地址空间满足你的申请（哪怕大小算错了），但free操作没有真正回收内存；第二次调用时，剩余虚拟地址空间已经被第一次泄漏的内存占满，malloc会返回空指针，而你没有检查malloc返回值就直接写入，自然会触发段错误崩溃。

3. 潜在的整数溢出风险 #

如果你的x、y、count变量是32位int类型，计算内存大小时如果运算顺序不对，会先触发32位有符号整数溢出，导致malloc实际申请的内存远小于需求，后续循环给megaarray[i]赋值时会直接写出界、破坏堆元数据，哪怕在原生Linux环境下也会出现free崩溃的问题。

• 修正第一级指针数组的分配大小，去掉多余的y乘数，计算大小时先把变量强转为size_t避免整数溢出，所有malloc操作必须检查返回值，分配失败时要回收已分配内存避免泄漏：

// 分配x*count个int*的存储空间，强转size_t避免整数溢出
megaarray = (int**)malloc( (size_t)x * count * sizeof(int*) );
if (megaarray == NULL) {
    perror("alloc megaarray failed");
    exit(EXIT_FAILURE);
}

for(int i=0; i<x * count; i++){
    megaarray[i] = (int*)malloc( (size_t)y * sizeof(int) );
    if (megaarray[i] == NULL) {
        // 释放之前已经分配成功的块，避免中间泄漏
        for (int j=0; j<i; j++) free(megaarray[j]);
        free(megaarray);
        perror("alloc sub array failed");
        exit(EXIT_FAILURE);
    }
}

• 修正代码后如果依然存在内存无法释放的问题，直接迁移到WSL2。WSL1的内存模拟层缺陷没有可靠的规避方案，尤其是大内存、海量小块分配的场景，WSL2使用原生Linux内核处理内存管理，不存在该类问题。

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