0

私は、その存続期間中に複数のスレッドを起動および破棄するプログラムを持っています。しばらくの間はすべて問題なく動作しますが、最終的に次のコア ダンプ スタック トレースが表示されます。

#0  0x009887a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x007617a5 in raise () from /lib/tls/libc.so.6
#2  0x00763209 in abort () from /lib/tls/libc.so.6
#3  0x003ec1bb in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6
#4  0x003e9ed1 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.6
#5  0x003e9f06 in std::terminate () from /usr/lib/libstdc++.so.6
#6  0x003ea04f in __cxa_throw () from /usr/lib/libstdc++.so.6
#7  0x00d5562b in boost::thread::start_thread () from /h/Program/bin/../lib/libboost_thread-gcc34-mt-1_39.so.1.39.0

最初は、スレッドをリークしていて、コアが現在のスレッド数の上限に達したことが原因であると考えましたが、今では、そうでない場合でもこの問題が発生するようです。参考までに、上記のコアでは、13 個のアクティブなスレッドが実行されていました。

start_thread がコアになる理由を突き止めるためにいくつかの検索を行いましたが、何も見つかりませんでした。誰にもアイデアはありますか？

4

2 に答える 2

2

start_threadがキャッチされていない例外をスローしている場合は、どの例外がstart_threadスローできるかを確認し、catchその周りに を配置して、何が問題かを確認してください。

于 2010-01-21T13:31:32.767 に答える
0

thread_resource_error によって運ばれる値は何ですか? native_error() を呼び出して調べることができるようです。

これは pthread のラッパーであるため、EAGAIN、EINVAL、および EPERM の 2 つの可能性しかありません。ブーストには、EINVAL および EPERM に対してスローされる可能性が高い例外があるように見えます-つまり、unsupported_thread_option() および thread_permission_error()。

それはほとんどEAGAINを残すので、スレッド数のシステム制限を実際に超えていないことを再確認します。あなたは彼らに参加していると確信していますか、それとも離れている場合、彼らは本当にいなくなっていますか?

于 2010-01-21T16:54:01.113 に答える