9

私の知る限り、std::bad_alloc がスローされる理由は 3 つあります。

  1. プロセスは、提供できるよりも多くのメモリを要求しています
  2. アドレス空間が断片化されすぎているため、連続したメモリの大きなチャンクに対する要求を処理できません
  3. ヒープ管理データ構造が壊れています

std::bad_alloc に実行されるコードがありますが、上記の理由のいずれも当てはまらないようです。データ構造は、頂点の std::list として格納されるグラフであり、各頂点は、それが含まれるエッジの std::list と、ある程度の連続データを格納します。

小さなグラフ (<= 100'000 頂点) の場合、プログラムは頂点ごとのデータ セクションの大きさに関係なく完全に正常に実行されます (合計で最大 40 GB を問題なく割り当てることができます)。ただし、頂点の数が増えると、8 GB のメモリしか使用しないインスタンスでも std::bad_alloc 例外がスローされます。

より大きなブロックに多くのメモリを割り当てても問題ないため、上記の理由 1. および 2. は除外する必要があります。非常にエラーが発生しやすい方法でポインターをいじるセクションがあるため、ヒープ データ構造が破損する可能性があります。しかし、小さなインスタンスで実行すると、valgrind の memcheck はコードに問題がないと報告するため、その理由もありそうにありません (インスタンスをスローすると、valgrind 自体がメモリ不足になるため、そのケースを直接確認することはできません)。

この動作の理由として他に何が考えられるか、または問題をさらに突き止めるためにどのようなテストを実行できるかについてのアイデアはありますか?

OS: Fedora 19
ビルドシステム: cmake with gcc 4.8.2

4

1 に答える 1

6

あなたの投稿にコメントできないので、返信します。

OpenFST を Kaldi (あなたと同じシステムと gcc) で使用しているときに、同じ問題に遭遇しました。この問題の正確な原因は追跡していませんが、カーネル 3.12 がここで問題になっているようです。バックアップ カーネルの 1 つ (3.11 シリーズの 1 つ) で起動したところ、問題はなくなりました。

以下を使用できます。

yum list --showduplicates kernel

利用可能な 3.11 カーネルを見つけます。

編集：

このバグは、カーネル 3.12.11-201 および 3.13 以降で修正されているようです。

ソース: Bugzilla

于 2014-02-10T09:37:44.243 に答える