Распределение TBB с выдачей сигнала уничтожения

Моя программа на C++ (работающая в Mac OS) была убита. После запуска отладчиком получаю следующее:

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

Таким образом, похоже, что сигнал уничтожения был выдан при распределении в пределах tbb::concurrent_vector<>. Однако ни документация для tbb::concurrent_vector::push_back(), ни документация для оператор new предлагает такое действие.

Является ли это недокументированным поведением TBB (предпочитаю завершить запущенный процесс, потому что TBB не может правильно обрабатывать с исключениями)? Как узнать и как этого избежать?


c++ new-operator c++11 tbb sigkill
person Walter    schedule 20.07.2019    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Вероятно, вам нужно оптимизировать свой алгоритм, чтобы использовать меньше памяти.

Я не знаю, как macOS обрабатывает выделение памяти, но в Linux, если вы используете слишком много памяти, «OOM Killer" отправит сигнал SIGKILL.

person clockwork_53    schedule 20.07.2019
comment
@Walter Надеюсь, вам не нужно полностью переосмысливать распределение памяти, и вместо этого есть более простой способ поймать неисправную новую или обработать/освободить память до того, как ОС убьет приложение из-за того, что она обнаружит как безудержный шаблон выделения (если это то, что на самом деле происходит) - stackoverflow.com/a/6834029/475228 - person bmike; 20.07.2019
comment
Теперь я понимаю, что выделение памяти было проблемой. Однако не должно ли это привести к тому, что оператор new выдаст исключение, а не исполняющая система уничтожит процесс? - person Walter; 20.07.2019
comment
@Walter не обязательно, вот что такое сверхкоммит. По сути, в большинстве Linux вы можете без проблем выделить 4 ТБ памяти, потому что ядро ​​​​не сразу предоставляет физическое хранилище для поддержки этой виртуальной памяти. В основном он надеется, что вы не собираетесь получать доступ к большей части выделенной вами памяти. Поведение на Macos, похоже, не задокументировано, но этот пост предполагает, что macos действительно перегружен. - person sbabbi; 21.07.2019
comment
Это будет так. Включите эту важную деталь в ответ для голосования (в настоящее время он не полностью отвечает на вопрос) - person Lightness Races in Orbit; 21.07.2019