我有一个程序，可以在整个生命周期中提出并删除多个线程。一切都运行良好一段时间，但最终，我获得了以下核心转储堆栈跟踪。
#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会核心，但我没有遇到任何问题。有人有什么想法吗？
答案 0 :(得分：2)
start_thread会抛出一个未被捕获的异常，看看start_thread可以抛出哪些异常并在其周围放置catch以查看问题所在。
答案 1 :(得分：0)
thread_resource_error携带的值是什么？看起来你可以调用native_error（）来查找。
由于这是pthreads的包装，因此只有几种可能性--EAGAIN，EINVAL和EPERM。看起来好像boost有可能为EINVAL和EPERM抛出的异常 - 即unsupported_thread_option（）和thread_permission_error（）。
这几乎离开了EAGAIN所以我会仔细检查你确实没有超过线程数量的系统限制。你确定要加入他们，或者如果超然，他们真的走了吗？