2009-08-28 6 views
2

ブーストのマトリックスライブラリとスパース行列ライブラリの両方を使用するプログラムがあり、ブーストスレッドを統合しようとしています。しかし、シングルスレッドのアプリケーションからマルチスレッドのアプリケーションに移行するとき、シングルスレッドのケースでは発生しないセグメンテーションフォルトが発生しています。マルチスレッドによるセグフルト(ブーストライブラリを使用)

私はgdb(Eclipseで)を使ってデバッグしました。ブーストコードで関数呼び出し中にsegフォルトが発生していることがわかりました。つまり、疎行列のエントリにアクセスしようとしました。コードとそれらのファイルのいくつかのポイント(常に同じポイントではない)で死ぬ。

これらの行列は個々のスレッド内に割り当てられ、すべての共有リソースはmutexロックによって保護されているので、私は混乱します。さらに、スレッド化はしばしばsegフォールト、多重アクセス、および不良データを引き起こすとは考えていませんでした。しかし、私は明らかにマルチスレッドプログラミングに慣れていないので、この分野でより経験豊富な人がアドバイスを提供できることを期待していました。私はブースト管理メイクシステムと例のコンパイルコマンドを使用してい

g++ -DNDEBUG -I"/usr/local/include/boost-1_38" -I/usr/local/include -I"/home/scandido/workspace/BigSHOT/src" -I"/home/scandido/workspace/BigSHOT/src/base" -O3 -Wall -c -fmessage-length=0 `freetype-config --cflags` -pthread -MMD -MP -MF"src/utils/timing_info.d" -MT"src/utils/timing_info.d" -o"src/utils/timing_info.o" "../src/utils/timing_info.cpp" 

で、リンカのコマンドは、ここで

g++ -L"/usr/local/lib" -L/usr/local/lib -o"BigSHOT" ./src/utils/timing_info.o ... many more objects ... ./src/base/pomdp/policy_fn/EventDriven.o ./src/base/pomdp/policy_fn/Greedy.o ./src/anotheralgorithm.o -lboost_serialization-gcc43-mt -lpthread -lboost_thread-gcc43-mt -lboost_program_options-gcc43-mt -lboost_iostreams-gcc43-mt -lpng -lpngwriter -lz -lfreetype 

が障害をワンセグスレッドのスタックトレースです。

Thread [5] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.) 
    17 boost::numeric::ublas::mapped_matrix<bool, boost::numeric::ublas::basic_row_major<unsigned long, long>, boost::numeric::ublas::map_std<unsigned long, bool, std::allocator<std::pair<unsigned long const, bool> > > >::operator() /usr/local/include/boost-1_38/boost/numeric/ublas/matrix_sparse.hpp:377 0x000000000041c328 
    16 BigSHOT::Fire1FireState::get_cell() /home/scandido/workspace/BigSHOT/src/systems/fire1/pomdp/Fire1State.cpp:51 0x0000000000419a75  
    15 BigSHOT::Fire1SquareRegionProbObsFn::operator() /home/scandido/workspace/BigSHOT/src/systems/fire1/obs_fn/Fire1SquareRegionProbObsFn.cpp:92 0x000000000042ac37 
    14 BigSHOT::Fire1SquareRegionProbObsFn::operator() /home/scandido/workspace/BigSHOT/src/systems/fire1/obs_fn/Fire1SquareRegionProbObsFn.cpp:66 0x000000000042a8bf 
    13 BigSHOT::BayesFilterFn<BigSHOT::Fire1Belief, BigSHOT::Fire1State, BigSHOT::Fire1Action, BigSHOT::Fire1Observation>::update() /home/scandido/workspace/BigSHOT/src/base/pomdp/filter_fn/BayesFilterFn.h:50 0x0000000000445c3b 
    12 BigSHOT::HyperParticleFilter<BigSHOT::Fire1Belief, BigSHOT::Fire1Action, BigSHOT::Fire1Observation>::future_evolution() /home/scandido/workspace/BigSHOT/src/base/hpf/HyperParticleFilter.h:127 0x00000000004308e0 
    11 BigSHOT::HyperParticleFilter<BigSHOT::Fire1Belief, BigSHOT::Fire1Action, BigSHOT::Fire1Observation>::hyperfilter() /home/scandido/workspace/BigSHOT/src/base/hpf/HyperParticleFilter.h:86 0x000000000043149b 
    10 BigSHOT::HyperParticleFilterSystem<BigSHOT::HyperCostFn<BigSHOT::Fire1Belief, BigSHOT::Fire1Action>, BigSHOT::PolicyFn<BigSHOT::Fire1Belief, BigSHOT::Fire1Action>, BigSHOT::Fire1Belief, BigSHOT::Fire1Action, BigSHOT::Fire1Observation>::next_stage() /home/scandido/workspace/BigSHOT/src/base/hpf/HyperParticleFilter.h:189 0x0000000000446180 
    9 hyperfilter() /home/scandido/workspace/BigSHOT/src/anotheralgorithm.cpp:126 0x0000000000437798  
    8 hf_thread_wrapper() /home/scandido/workspace/BigSHOT/src/anotheralgorithm.cpp:281 0x0000000000437cd9 
    7 boost::_bi::list1<boost::_bi::value<int> >::operator()<void (*)(int), boost::_bi::list0>() /usr/local/include/boost-1_38/boost/bind.hpp:232 0x000000000043f25a  
    6 boost::_bi::bind_t<void, void (*)(int), boost::_bi::list1<boost::_bi::value<int> > >::operator() /usr/local/include/boost-1_38/boost/bind/bind_template.hpp:20 0x000000000043f298 
    5 boost::detail::thread_data<boost::_bi::bind_t<void, void (*)(int), boost::_bi::list1<boost::_bi::value<int> > > >::run() /usr/local/include/boost-1_38/boost/thread/detail/thread.hpp:56 0x000000000043f2b6 
    4 thread_proxy() 0x00007f28241c893f  
    3 start_thread() 0x00007f28243d93ba  
    2 clone() 0x00007f2822a4ffcd 
    1 <symbol is not available> 0x0000000000000000 

コードの行は、このブロックの2番目です。

const_reference operator() (size_type i, size_type j) const { 
    const size_type element = layout_type::element (i, size1_, j, size2_); 
    const_subiterator_type it (data().find (element)); 

segフォルトが常にコード内の同じ場所で発生するとは限りませんが、常にブーストコードで何かを実行していることを再確認したいと思います。

ご協力いただきありがとうございます。

+3

まず、アプリケーションの* all *がコンパイラに対して-pthreadオプションを使用してコンパイルされていることを確認します。すべての単一のオブジェクトファイル。クラッシュがまだ残っている場合は、実際のバックトレースを投稿してください。 –

+0

私は正しいコンパイルオプションを持っていると思いますが、私は確信していません。 "--pthread"がそこにあります。質問テキストにサンプルを追加しましたが、正しく表示されますか? – RandomGuy

+0

スタックトレースも追加しました。ありがとう。 – RandomGuy

答えて

5

Segfaultsは、ヒープやフリーストアを破損した場合、例えばポインタをダブルフリーズ(または二重削除)するなどして、よくデバッグされた他のライブラリから(または標準ライブラリからでも)すでに解放された(または削除された)ポインタへのアクセス、割り当てられていないポインタの解放(または削除)、delete []またはその逆の使用が必要な場所の削除などを使用します。

このクラッシュは頻繁に発生しますまったく異なる場所で、エラーが発生した場所と場所とはまったく異なる時期に発生します。複数のスレッドで共有されている行列以外の変数があり、たとえば共有変数を二重削除する競合条件があると、フリーストアが破損し、後でブースト・マトリックス内でクラッシュする可能性がありますコード。

ヒープ/フリーストアの破損を追跡するために、valgrindのようなツールを使用してコードを実行する必要があります。

+0

提案していただきありがとうございます。ブーストのshared_ptr(スマートポインタ)を使用しているので、メモリを間違って削除しても問題ではないと確信しています。 (スレッド化されたコードには削除文はありません。)スレッド間で共有されるオブジェクトは1つのみで、スレッドの開始時と終了時にデータにアクセスしてデータをコピーして戻します。スレッド間の同時アクセスを防ぐためにロックを使用しています。私がここで検討していないものはありますか? – RandomGuy

+0

私は前にvalgrindを使ったことはありません。自分のサイトのドキュメント以外のチュートリアルをお勧めしますか? – RandomGuy

+0

valgrindは使い方が簡単です。時には課題である出力を理解しています。このようなプログラムを実行するために本当に必要なのは、デバッグシンボルでコンパイルしてから実行してください:valgrind --tool = memcheck ./yourapp。メモリアクセスエラーごとに、発生した場所、エラーの種類、そして互換性のない操作が発生した場所を示す1つまたは2つの省略されたスタックトレースを表示します。残念なことに私が知る限り、公式の文書よりも優れたリソースはありません。それはあなたが必要なので、memcheckのセクションを見てください。 –

関連する問題