1

この小さなプログラムを考えてみましょう。

#include <stdio.h>
#include <stdlib.h>

// Change 60000 to 70000 and valgrind (memcheck) eats my memory
#define L (60000)
#define M (100*(1<<20))

int main(void) {
  int i;
  for (i = 0; i < M; ++i) {
    unsigned char *a = malloc(L);
    a[i % L] = i % 128; // Touch something; a[0] is not enough
    free(a);
    if (i % (1<<16) == 0)
      fprintf(stderr, "i = %d\n", i);
  }
  return 0;
}

memcheckはメモリの約1.5％を使用しており、コンパイルgcc -o vgと実行は正常に機能します。valgrind --leak-check=full ./vgただし、Lを70000に変更すると（魔法の制限は1 << 16だと思います）、カーネルが最終的にそれを強制終了するまで、memcheckは増え続けるメモリを使用します。

これについて何かできることはありますか？明らかにリークはありませんが、valgrind自体にリークがあるように見え（！？）、大量の短期間の割り当てが多いプログラムのチェックには使用が困難です。

いくつかの背景、どちらが関連しているかわからない：

$ valgrind --version
valgrind-3.7.0
$ gcc --version
gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)
$ /lib/libc.so.6
GNU C Library stable release version 2.12, by Roland McGrath et al.
$ uname -rms
Linux 2.6.32-220.2.1.el6.x86_64 x86_64
4

2 に答える 2

1

これは、valgrind 3.8.0（まだリリースされていない）でバイパスされるgcc4.4のバグが原因である可能性が非常に高いです。

Valgrind 3.8.0 NEWSファイルからの抽出：

ni-bz gcc4.4 / 4.5の誤ったコード生成をバイパスすると、メモリ不足またはアサートが発生します

于 2012-06-23T15:48:28.320 に答える
0

を使用してプロセスのリソース制限を無制限に設定します。setrlimitこれにより、男性の制限を超えてもカーネルがプロセスを強制終了しません。したがって、カーネルは、仮想アドレス空間に拡張しても問題ないと考えます。

お役に立てれば。

于 2012-05-11T20:02:58.630 に答える