3

私は valgrind の大ファンで、コードのバグを見つけるために広く使用しています。ただし、現在、特定の状況でのみ発生するバグに悩まされており、プログラムで32Gbを超えるRAM（実際には約37）をmalloc/使用する必要があり、valgrindにはハードコーディングされた制限がありません32Gb 以上を割り当てましょう。この制限を拡張できるようにする valgrind へのさまざまなコード変更を人々がリストしているオンラインの投稿をいくつか見つけることができましたが、それらは機能していないように見えるか、別の (および未指定の) バージョンを変更しているようですvalgrind の。いずれにせよ、私は valgrind の内部をハッキングすることに熱心ではないので、他のオプションを探し始めました。

Clang/AddressSanitizer は良い選択肢のように思えましたが、ネストされた関数を多用しているため、残念ながらそこにも問題があります。だから、私の質問は - (64 ビット Linux で) valgrind が行う 32Gb のメモリ割り当て制限がない valgrind の代替手段を知っている人はいますか?

アイデア v ウェルカム ベスト ザム

4

2 に答える 2

1

AddressSanitizer の gcc バリアントが gcc トランク (間もなく 4.8) で利用できるようになりました。これはまだ clang バージョンほど成熟していませんが、試してみてください。

% cat use-after-free.cc 
#include <stdlib.h>
int main() {
  char *x = (char*)malloc(10 * sizeof(char));
  free(x);
  return x[5];
}
% g++ --version | head -1 
g++ (GCC) 4.8.0 20130216 (experimental)

% g++ -fsanitize=address -static-libasan  use-after-free.cc && ./a.out 2>&1 | asan_symbolize.py 
=================================================================
==9817== ERROR: AddressSanitizer: heap-use-after-free on address 0x60040000dff5 at pc 0x4179c3 bp 0x7fffe046af30 sp 0x7fffe046af28
READ of size 1 at 0x60040000dff5 thread T0
    #0 0x4179c2 in main ??:0
    #1 0x7f469c8dc76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
    #2 0x402098 in _start ??:0
0x60040000dff5 is located 5 bytes inside of 10-byte region [0x60040000dff0,0x60040000dffa)
freed by thread T0 here:
    #0 0x40f18a in free ??:0
    #1 0x417980 in main ??:0
    #2 0x7f469c8dc76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
previously allocated by thread T0 here:
    #0 0x40f26a in malloc ??:0
    #1 0x417970 in main ??:0
    #2 0x7f469c8dc76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
于 2013-02-21T11:54:56.860 に答える
0

LinuxおよびWindows用のオープンソースメモリデバッガもあります。それは「Dr.Memory」と呼ばれています。上限があるかどうかはわかりませんが（valgrindのように）、試してみてください。

于 2012-12-22T09:01:37.923 に答える