boost sparse_matrixの要素にアクセスすると、プログラムが停止するようです。

Question

私はプログラマが経験を積んだと思う奇妙なバグがあります。私はboostas ubasスパース行列、特にmapped_matrixを使用していますが、最終的には発生する断続的なバグがありますが、プログラムの初期段階では発生しません。これは、大規模プログラムであるので、私はすべてのコードを投稿することはできないが、核となるアイデアは、私は特定のクラスに属する関数を呼び出すことである：変数cはクラスのメンバーとして定義される

bool MyClass::get_cell(unsigned int i, unsigned int j) const 
{ 
    return c(i,j); 
} 

を

boost::numeric::ublas::mapped_matrix<bool> c; 

バグが発生すると、プログラムが停止したように見えますが、クラッシュしません。 Eclipseでデバッグすると、プログラムがboost mapped_matrixコードに入り、いくつかのレベルがstd :: map、std :: _ Rb_tree、およびstd :: lessに続くことがわかります。また、時々プログラムはstd :: map、std :: _ Rb_tree、std :: _ Select1stまでトレースします。コードが実行されていて、_Rb_treeでメモリ内の何が変更されているのかはわかりませんが、実行はstd :: mapのレベルでは決して戻りません。プログラムがstd :: map内にある行は、次の関数の返り値です。

const_iterator 
find(const key_type& __x) const 
{ return _M_t.find(__x); } 

は、いくつかのプログラムが探しているC行列の要素何とかなるストレージ・メカニズムがある「見当違いのこと」があるように私には思えます。しかし、それをどうやって修正するのか分かりません。それはまた、完全に基盤から離れている可能性があります。

ご提供いただけるご支援をいただければ幸いです。この質問に適切な情報が含まれていない場合は、私に何が欠けているか教えてください。ありがとうございました。

Answer 1

コード（必ずしも永続的な変更）デバッグしようとするいくつかのもの：行列は数値型を期待かどうかを確認するために、c用マトリクス型でintにbool

• 変更を。
• 同様のインターフェイスを持つマトリックスタイプを別のものに変更してください。おそらく普通の古いmatrixです。
• メモリを破壊していないことを確認するために、アプリケーションをValgrind（Linuxの場合）してください。

これが失敗した場合は、マトリックスを変更して問題の原因となるものがあるかどうかを確認するたびにget_cellを呼び出すことができます。

この問題を解決するには、ここに投稿できるコードのサブセットをもっと小さくする必要があります。

使用しているコンパイラとOSを教えてください。

Answer 2

マルチスレッドプログラムのこの部分はありますか？

通常、STLで問題が発生すると、同期されていないアクセスで問題が発生するため、尋ねます。