все нормально или какой нибудь зависимости нету ?
присутствует ли
и не повреждена ли
libthread_db.so.1
libthread_db.so.1
-- это библиотека интеграции libc с отладчиком, никакие приложения её сами по себе не используют. приложения стали падать с ошибкой сегментации сразу после вызова. Что интересно - если запустить их из-под GDB - приложения спокойно себе работают...
LD_LIBRARY_PATH
/LD_PRELOAD
. Посмотри/покажи, что у тебя в переменных окружения. Попробуй очистить эти переменные и запустить падающие приложения в таком состоянии. Сравни вывод printenv
в консоли (при запуске из которой приложение падает) с выводом show environment
в gdb (при запуске из которого приложение работает). поэтому до появления override было сложно понять, что производный класс предоставляет виртуальные методы?
override
гарантирует, что если в базовом классе функция не виртуальная, то код не соберётся. Как я понимаю, эта фича нацелена на поддержку случая, когда может потребоваться менять определения виртуальных функций базового класса: с использованием override
наследники которые не обновлены вслед за базовым классом не скомпилируются, а без использования функциональность наследников будет просто молча поломана. Подозреваю, что в случае гиганских размеров std::array есть вероятность, что он может быть расположен в куче (подтверждений и опровержений этому не нашел!).
An array is an aggregate
, из чего следует, что он целиком размещается в одном месте, вне зависимости от размеров.
А в приведённой записи что не устраивает?