samedi 20 juillet 2019

tbb allocation issuing a kill signal?

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