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ループごとに1回メモリを割り当てて解放しています。また、nptperf[file]通常は約1〜300万ポイント、そしてngridx = ngridy = 100。

このプログラムはngridx = ngridy = 80以下で動作しますが、で失敗し100ます。

4

4 に答える 4

3

ggループの本体内で（およびggyの代わりにxx）間違った変数を使用していますyy。他の問題の中でも、これにより、calloc()edポインタが失われるため、割り当てられたメモリの（ほぼ）すべてがリークされます。

于 2012-11-08T08:59:08.707 に答える
1

2つの可能性があります：

  1. free()失敗する可能性があります。つまり、使用したメモリを解放しないということです（質問）
  2. プログラムにバグがあり、使用したメモリを解放しないと、メモリリークが発生します。

最初のものは起こりそうにありません、私はfree()適切に使用された場合に失敗する状況を知りません。適切なポインタが渡されると、そのメモリは解放されます。渡さNULLれると、何も実行されません。

2番目の可能性が高くなりますが、上記のスニペットでは問題ないように見えます。上記のように、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からの戻り値を確認することをお勧めします。

プログラムに大量のメモリが必要な場合は、要件を処理するのに十分なスワップスペースがあることを確認してください。システム上で実行されている他のアプリもある可能性があることに注意してください。

もう1つのオプションは、分割統治法です。1つの可能性は、それを複数のマシンで実行される分散アプリケーションに変えることです。アプリケーションの残りの部分が何をするかを知らなくても、これは実行可能かどうかはわかりません。

于 2012-11-10T01:55:42.567 に答える