2010-12-02 6 views
0

このエラーについてすべてを説明するのは少し難しいかもしれませんが、私は最善を尽くします。残念ながら、コードは非常に大きいので、コードを含めると実用的ではありません。新規呼び出し時のメモリ不足

私は宿題(あなたが知る必要がある場合はナッソス)のための学術的なOSを書いています。私がする必要があったのは、コアマップに相互排除を実装することでした。これを行うために、エミュレートされたメインメモリにページごとにLockと条件変数を追加しました。これを実行した後、私のコードを実行し、(コアマップとはまったく別のディレクトリにある)例外ハンドラを呼び出すだけですが、関数が呼び出されるのを2回目にして、次の呼び出しでエラーが発生します:r=new Lock("read");このように:

*** glibc detected *** /home/some_other_directories/workspace/nachos3_repo/vm/nachos: malloc(): memory corruption (fast): 0x0805fe20 *** 

ちょうどそれは私が私のシステムファイル内でexternようにそのロックの割り当てを変更し(そこにグローバル外部宣言が多い)、その後、私は上のワンセグ障害を取得するどのように動作するか確認してくださいfout.open("old.txt");を呼び出して、newを呼び出してmallocの呼び出し内にスタックをトレースバックしました。

私の最高の推測は、私のヒープが大きくなっているということですが、それが本当であるかどうか、それがどうか処理されるかどうかはわかりません。誰もこの問題を解明できますか?

+0

Valgrindを試しましたか? –

+1

メモリ上書きの問題があります。あなたのCコードのどこかに、バッファの終わりを越えて(あるいはそうでなければ)書き、実行時に使用されている基礎となるデータ構造を切り捨てます。 valgrindまたはC++で、デバッグモードでSTLの境界チェックがオンになっています。 –

+0

私は少し新しく、valgrindからのすべての出力を理解するのに苦労しており、それを学ぶには膨大な時間を要しません。私はまだそれを見てしようとしています。 – user381261

答えて

1

mallocはここだけの犠牲者です。コードの完全に異なる部分では、割り当てられた境界の外で書かれているため、ヒープマネージャが空き/割り当てブロックを追跡するために使用する破損チェーンリンクを持っています。ここで割り当てようとすると、ヒープマネージャーは、これらのリンクリストと土地を(おそらく割り当てられていない)保護されたエリアに追い込んでいます。 の最初の変更をに変更し、メモリを書き換え可能な場所を見つけることができるかどうかを確認する必要があります。

+0

それは悪い削除だった、誰かが私がvalgrindを把握するのを助けた。 – user381261

+1

これはうまくいった。あなたの運が1時間以内にそれを追跡する... –