My C++ program (running on Mac OS) got killed. Upon running with a debugger, I obtain the following:
Process 90937 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGKILL
frame #0: 0x000000010001fc50 captureISO`tbb::interface9::internal::start_for<WDutils::Parallel::details::blocked_range_terminating<unsigned long>, (anonymous namespace)::simulations::sampleSome(bool)::$_2, tbb::auto_partitioner const>::run_body(WDutils::Parallel::details::blocked_range_terminating<unsigned long>&) [inlined] tbb::concurrent_vector<(anonymous namespace)::simulations::initialCondition, tbb::cache_aligned_allocator<(anonymous namespace)::simulations::initialCondition> >::push_back(this=0x00007fff5fbfebd0)::simulations::initialCondition const&) at concurrent_vector.h:846 [opt]
843 iterator push_back( const_reference item )
844 {
845 push_back_helper prolog(*this);
-> 846 new(prolog.internal_push_back_result()) T(item);
847 return prolog.return_iterator_and_dismiss();
848 }
849
So, it appears that the kill signal was issued by allocation within tbb::concurrent_vector<>
. However, neither the documentation for tbb::concurrent_vector::push_back()
nor that for operator new
suggest such action.
Is this an undocumented behaviour of tbb (prefer to kill the running process, because tbb cannot deal appropriately with exceptions)? How can I find out and how can I avoid this?
Aucun commentaire:
Enregistrer un commentaire