0

大規模なソフトウェアでのメモリ トランプルの問題に直面しています。

SIGSEGV/SIGABRT が観察されることがあります。理由は、主にユーザーまたは malloc スペース メモリを踏みにじることです。mprotect-ed メモリを「餌」として試してみましたが、うまくいきませんでした。実際にはトランプラーを捕まえることができません。コアファイルの分析から、malloc領域(現在のチャンクサイズ)でも破損が発生しているようです。破損は常に 1 バイトであり、どこでも発生します (0xFF00FF00 が 0xFF003A00 で破損するなど、オーバーフロー/アンダーフローと呼ぶことができるようなパターンを意味します)。

可能な調査方法に関する提案はありますか??

PS -- valgrind を取り付けることはできません。

前もって感謝します 。

4

3 に答える 3

1

あなたが試すことができるいくつかのトリックがあります。まず、ヒープの一貫性を確認してください。こちらを参照してください。

DEDEDEDE をすべての解放されたメモリに書き込むフックを書きたいと思うかもしれません。

于 2012-08-06T14:15:32.943 に答える
1

libc の代わりにシステムにリンクする、さまざまな形式の健全性チェックを備えた代替ヒープ実装がいくつもあります。一般的な手法は次のとおりです。

  • リクエストよりも大きなブロックを割り当て、リクエストされたブロックの最初と最後にガードゾーンを配置する
  • 割り当てごとに 1 ページ、どちらの側にもアクセスできないページ (たとえば、すべてのアクセスでのページ フォールト)
  • 割り当てられたブロックと割り当て解除されたブロックの追跡
  • 悪いものを探して優先度の低いスレッドでヒープを歩く

数年前、私は組み込みシステムでこのような問題を見つけるのに非常に長い時間を費やしました。机の上でユニットをクラッシュさせたことはありません。徹底的なコード監査やコードベース全体の PCLint 化など、本のほとんどすべてのトリックを試しました。

最終的に、両方のシステムで SDRAM のスピード グレードが間違っていることが原因であることがわかりました。クラッシュしたものは、私の机の上にあるものよりもわずかに限界がありました。最終的には、ヘアドライヤーとフリーザースプレーの缶で決定的に証明されました:/

繰り返し踏みにじられる場所を確認できる場合は、次の寄港地として、ハードウェア支援デバッグ (最近ではほとんどの CPU でこれが許可されています) または ICE または JTAG ベースのデバッガーを使用することになります。

于 2012-08-08T22:09:30.847 に答える
0

何らかの奇跡によって、同じメモリの場所が連続して実行された場合 (または少なくとも 25% の確率で) 破損するようにできる場合は、そのメモリの場所で gdb のデータ ブレークポイントを使用できます。

そうでない場合は、別のハードウェアで S/W を試して、ハードウェア メモリ エラーを除外しましたか? まれに、そのようなことがまだ発生する可能性があります。

libumemまたは google のアロケータなどのアロケータをプリロードして、メモリの問題を検出できるかどうかを確認することもできます。

これはオプションではないとあなたが言ったことは知っていますが、何らかの方法で問題をより小さなコードセットに絞り込むことができれば、それはvalgrind本当に良いことです-それは何度も私を助けてくれました.

最後に、これらのオプションのいずれも実を結ばない場合は、より重いものにする必要があります。

  • 何らかの方法でデータ構造の健全性をチェックできる場合は、コードにそのようなチェックを散らかしてください。
  • コードの削除を開始し、問題が解決するかどうかを確認してください。
  • コードの疑わしい部分を最初からリファクタリングまたは書き直します。
  • 影響を受ける領域の一部またはすべてのコードの複数人によるピア レビュー。1 人はコードに精通しており、もう 1 人はドメインの知識はあるがコードを知らないことが望ましいです (なぜなら、コードが何を言っていると考えているのかわからない場合は、レビューするときにバグがずっと簡単に見つかるからです)。
于 2012-08-07T13:46:20.493 に答える