2

如果我像这样在循环中分配内存

for(file = 0; file < nfile; file++){
...
...
...
   for(yy = 0; yy < ngridy; yy++){
      for(xx = 0; xx < ngridx; xx++) {
         tmparr1[xx+(ngridx*yy)] = (double *)calloc(nptperf[file], sizeof(double));
         tmparr2[xx+(ngridx*yy)] = (double *)calloc(nptperf[file], sizeof(double));
      }
   }

稍后在代码中的某个时候，我会像这样释放内存：

for(yy = 0; yy < ngridy; yy++){
    for(xx = 0; xx < ngridx; xx++) {
       free(tmparr1[xx+(ngridx*yy)]);
       free(tmparr2[xx+(ngridx*yy)]);
    }
}

是否有可能free()不释放内存并因此导致分配更多内存？我在每个file循环中分配和释放一次内存。此外，nptperf[file]通常在 1-3 百万点左右，并且ngridx = ngridy = 100.

该程序适用于ngridx = ngridy = 80和更少，但在100.

4

4 回答 4

3

您在循环体内使用了错误的变量（ggandggy而不是xxand yy）。除其他问题外，这会导致（几乎）所有分配的内存泄漏，因为您丢失了calloc()ed 指针。

于 2012-11-08T08:59:08.707 回答
1

有两种可能：

  1. free()可能会失败，这意味着您没有释放您使用的内存（您的问题）
  2. 你的程序有一个错误，你没有释放你使用的内存，你正在泄漏内存。

第一个不太可能发生，我不知道free()如果使用得当会失败的任何情况。如果传递了正确的指针，则该内存将被释放，如果传递NULL，它将什么也不做。

第二个更有可能发生，但在上面的代码片段中它看起来没问题。如上所述，您可以使用Valgrind (/ˈvælɡrɪnd/) 检查是否出现问题。编译 -O0 -ggdb并让 Valgrind 检查分配和释放。

于 2012-11-08T09:21:03.483 回答
0

用你的程序运行一个像Valgrind这样的工具，看看你是否泄漏了任何内存。从您发布的代码来看，您似乎没有泄漏内存。但是使用 Valgrind 将证实这一点，并且它还可以指出可能存在的其他问题。

于 2012-11-08T08:58:23.403 回答
0

程序可能内存不足，calloc 返回 null，随后内存损坏并最终被杀死。

我建议检查 calloc 的返回值，而不是假设它成功了。

如果程序需要大量内存，请确保有足够的交换空间来处理需求。请记住，系统上可能还有其他应用程序正在运行。

另一种选择是分而治之。一种可能性是将其变成在多台机器上运行的分布式应用程序。在不知道应用程序的其余部分做什么的情况下，这可能可行，也可能不可行。

于 2012-11-10T01:55:42.567 回答