4

メモリ セグメントの動的配列によってメイン メモリを複製する宿題の C コードを書いています。

これらのメモリ セグメントは、それ自体が uint32_ts の単なる静的配列である別のインターフェイスから取得されます。

私のメイン メモリ インターフェイスは heapmem (ヒープ メモリのように) と呼ばれ、スイッチ以来、奇妙な valgrind 読み取り/書き込みエラーが発生しています。私を噛む前に、私は調べて調査し、最後の手段としてSOに来ています。

ここにエラーがあります

==30352== Invalid write of size 8
==30352==    at 0x401661: HeapMem_map (heapmem.c:84)
==30352==    by 0x400E74: map (um.c:109)
==30352==    by 0x4010FD: runOpcode (um.c:182)
==30352==    by 0x4011A1: UM_run (um.c:209)
==30352==    by 0x400A71: main (main.c:10)
==30352==  Address 0x4c53b00 is 0 bytes after a block of size 16 alloc'd
==30352==    at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==30352==    by 0x401425: HeapMem_new (heapmem.c:32)
==30352==    by 0x400ABE: UM_new (um.c:31)
==30352==    by 0x400A64: main (main.c:8)
==30352== 
==30352== Invalid read of size 8
==30352==    at 0x401787: HeapMem_put (heapmem.c:114)
==30352==    by 0x400D38: sstore (um.c:90)
==30352==    by 0x401090: runOpcode (um.c:167)
==30352==    by 0x4011A1: UM_run (um.c:209)
==30352==    by 0x400A71: main (main.c:10)
==30352==  Address 0x4c53b00 is 0 bytes after a block of size 16 alloc'd
==30352==    at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==30352==    by 0x401425: HeapMem_new (heapmem.c:32)
==30352==    by 0x400ABE: UM_new (um.c:31)
==30352==    by 0x400A64: main (main.c:8)
==30352== 
==30352== Invalid read of size 8
==30352==    at 0x401956: car_double (heapmem.c:151)
==30352==    by 0x401640: HeapMem_map (heapmem.c:82)
==30352==    by 0x400E74: map (um.c:109)
==30352==    by 0x4010FD: runOpcode (um.c:182)
==30352==    by 0x4011A1: UM_run (um.c:209)
==30352==    by 0x400A71: main (main.c:10)
==30352==  Address 0x4c53b00 is 0 bytes after a block of size 16 alloc'd
==30352==    at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==30352==    by 0x401425: HeapMem_new (heapmem.c:32)
==30352==    by 0x400ABE: UM_new (um.c:31)
==30352==    by 0x400A64: main (main.c:8)
==30352== 
==30352== Invalid read of size 8
==30352==    at 0x40174A: HeapMem_get (heapmem.c:108)
==30352==    by 0x400CD9: sload (um.c:86)
==30352==    by 0x401079: runOpcode (um.c:164)
==30352==    by 0x4011A1: UM_run (um.c:209)
==30352==    by 0x400A71: main (main.c:10)
==30352==  Address 0x4c7e0f0 is 0 bytes after a block of size 4,096 alloc'd
==30352==    at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==30352==    by 0x401923: car_double (heapmem.c:148)
==30352==    by 0x401640: HeapMem_map (heapmem.c:82)
==30352==    by 0x400E74: map (um.c:109)
==30352==    by 0x4010FD: runOpcode (um.c:182)
==30352==    by 0x4011A1: UM_run (um.c:209)
==30352==    by 0x400A71: main (main.c:10)

エラーが発生するコード内の関数は次のとおりです。

//  Heap Memory Structure
struct T {
   Stack_T SegID_stack;
   MemSeg_T* HeapMem_car;
   int length, highest;
};

//  Create a new heap memory structure
T HeapMem_new (MemSeg_T program) {
    assert (program);
    T retHeap = malloc(sizeof(*retHeap));
    Stack_T structStack = Stack_new ();
    retHeap->length = INIT_SIZE;
    retHeap->highest = 0;
    MemSeg_T* structCar = malloc(INIT_SIZE * sizeof(*structCar));
    //  Fill the array with NULL ptrs
    for (int i = 0; i < INIT_SIZE; i++) {
        structCar[i] = NULL;
    }
    retHeap->HeapMem_car = structCar;
    retHeap->SegID_stack = structStack;
    //  We'll be using the map function to initialize
    //  the heap with a program at the 0th segment.
    HeapMem_map (retHeap, MemSeg_length (program));
    retHeap->HeapMem_car[PROGRAM_LOC] = program;
    return retHeap;
}

//  Line 84
heapmem->HeapMem_car[toMap] = segment;
//  Line 114
MemSeg_T segToPut = heapmem->HeapMem_car[toPut];
//  Line 151
newCar[i] = heapmem->HeapMem_car[i];
//  Line 108
MemSeg_T wordSeg = heapmem->HeapMem_car[toGet];

残りのコードはこちらから入手できます。

4

1 に答える 1

11

まず、エラーの1 つの小さな分析:

==30352== Invalid write of size 8
==30352==    at 0x401661: HeapMem_map (heapmem.c:84)
==30352==    by 0x400E74: map (um.c:109)
==30352==    by 0x4010FD: runOpcode (um.c:182)
==30352==    by 0x4011A1: UM_run (um.c:209)
==30352==    by 0x400A71: main (main.c:10)
==30352==  Address 0x4c53b00 is 0 bytes after a block of size 16 alloc'd
==30352==    at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==30352==    by 0x401425: HeapMem_new (heapmem.c:32)
==30352==    by 0x400ABE: UM_new (um.c:31)
==30352==    by 0x400A64: main (main.c:8)

このリストの一番下には、割り当てが行われた場所が示されていることに注意してください。トップは、それがどのように悪用されたかを示しています。この場合、要求された割り当ての最後を正確に 8 バイト過ぎています。

この中にすべてのオーバーランがあり、残りの違反がまったく同じオフセット (8 バイト) だけ平均を超えていることに気付くでしょう。参照されているコードをさらに調べると、常に同じ配列であることがわかります。これは実際には良いことです。データ項目がいくつ存在するかを誤って計算し、許可されたスペースを 1 つまたは 2 つ超えてしまう可能性が非常に高いためです。

この場合、侵害されているアイテムは動的に割り当てられたポインターのリスト ( heapmem->HeapMem_car[]) のように見えます。64 ビット ポインターを備えたマシンで実行すると、それぞれが 8 バイト幅になるため、この割り当ての最後の要素からアクセス可能な要素と C では、1 つずつずれている可能性があります。Nアイテムを割り当ててからarray[N]、制限を忘れてアクセスしたポイントは ですN-1。上記のアクセス違反はすべて、その配列へのインデックスが範囲外ではないという信念を中心にしているように見えますが、valgrind は範囲外であると報告しています。これらのアクセス ポイントにいくつかの assert() を挿入し、違反で中断して、どのようにそこに到達したかを確認することをお勧めします。ちょっと待って.. valgrind にはすでにその情報があります。その素敵なコール スタックを見てください。うーん...

では、なぜこれらの侵害があっても機能しているように見えるのでしょうか? いくつかの可能性。割り当てられたメモリの外に出ない場合 (ここにあるすべてのアドレスは 0 バイト後です) (これらは結局のところポインタなので、NULL であることを祈ります) 重要なデータとプログラムを上書きしない可能性が高くなります。動作するようです。割り当てが突然別の場所に着地し、ページ境界をまたぐまで。それとカーブームをオーバーシュートします。

この回答の 2 番目の部分に貢献してくれたDaniel Fischerに感謝します (なぜうまくいくように見えるのか)。

于 2012-11-20T22:35:08.280 に答える