std::vector валится на push_back/emplace_back с сегфолтом О_О

Там realloc. Может он не всегда может память выделить?

версию gcc.

strace, gdb в руки и вперед.

Что говорит valgrind?

там разыменования на пуше нет случайно?

как правило, подобные косяки вылезают не с самим вектором, а с обращениями к нему, когда программисты ошибочно пытаются использовать где-то указатели на объекты внутри вектора. и при очередном пополнении он передислоцирует память (в связи с требованием связности хранения) и все указатели становятся невалидны.

Вариантов может быть уйма - выделение памяти, праблы в конструкторах копирования/перемещения и т. п.

Дай тестовый код, который воспроизводит проблему. (А скорее всего ты ее сам найдешь, когда будешь вырезать все лишнее, чтобы сделать тестовый код :) )

vector::emplace_back() у меня перманентно валился с сегфолтом, пришлось убрать.

странно это. вы ведь не в одиночку используете STL и нигде ничего про подобные ошибки. если бы в STL был баг, скорее всего, на следующий день после заявления о нём он бы уже был пофикшен.
скорее всего, косяки в программе. как-то: указатели, ссылки на объекты вектора, попытки работы с итераторами при изменении вектора и т.д.

ХЗ... это происходит на овер миллионной итерации цикла. Заговолок вектора тоже в куче. Ошибка стабильно воспроизводилась (в смысле номера итерации) от запуска к запуску.

Щас новая напасть - после emplace_back-ов и swap-ов грохается деструктор вектора. Ошибка уже немношко плавает, но недалеко.

Под ним невозможно запуститься (считать будет до утра)

Ты где-то память запорол, прогоняй valgrind'ом.

Тестовый код воспроизводящий трабл сделать почти невозможно - это боевой код юзающий на входе неск гб данных с кужой и пр фигней. Проще переписать проюлемный кусок на другом контейнере.

А ты уверен, что проблема в векторе, а не в типе элемента? Может в конструкторе/деструкторе что-то?

Под ним невозможно запуститься (считать будет до утра)

Попробуй dmalloc, может с ним быстрее будет.

Ьам pod тип. Уверен.

боевой код валится на сайзе, равном 16? тогда к чему все эти гигабайты и прочее?
контейнер обвинить проще всего. найти баг в коде бывает сложнее.

Ьам этих векторов неск.млн.

это происходит на овер миллионной итерации цикла

Потестируйте память. Или позапускайте на другом железе

Спасибо,мысдь хорошая. Не факт правда что осуществимо, но попробуем:-)

и что, нельзя создать тест на несколько миллионов векторов, размером по 16? ну, сожрёт он пару сотен метров в памяти, и что? это на любом ноутбуке можно проверить.

на входе неск гб данных

А там точно не std::bad_alloc прилетает?

Опять же, надо посмотреть, не пользуются ли какие-нить итераторы после реаллока в векторе.

многопоточность используется?

Нет, ну Вы можете прийти и попробовать - я в Вас верю!:-)

В этом месте нет.

А хз. Оно грит сегфолт. Итераторы вообще не используются, в любом случае это гавкнулось бы раньше.

При разработке этого дела тесты валгринд проходил чисто.

Как вариант запустить из-под gdb и получить стек вызовов или даже взять дамп, если есть.

Можно ещё попробовать собрать код с -fsanitizer=address. Попробовать прогнать с -Werror -Wall в gcc и clang, или через scan-build.

пустой вектор на стеке. делаю emplace_back(агрументы_конструктору), получаю сегфолт на этой же строке. делаю obj(агрументы_конструктору) + push_back() - все олично. было на gcc-4.8 вроде.

Может какой-нибудь счётчик переполняется?

При разработке этого дела тесты валгринд проходил чисто.

Тесты под valgrind'ом редко включают в себя проверки на гигабайтах данных. Многие ошибки отсечения старших 32 бит у 64-битного числа так не отловишь.

Ну не у меня. У stl м.б.

Я пожалуй просто перепишу проблемный кусок что бы не было реаллоков:-)

да я покрупнее системы отлаживала. гигабайты у нас за секунды сливались и обрабатывались в риалтайме. причём падение софта могло вызвать поломку харда и убытки на тысячи баксов. так что эмулировали и тестировали. тесты на то и есть тесты, чтобы проверять. а просто плакаться на ЛОРе, что STL плохой - это как-то несерьёзно.

Ещё можно просто собрать шлангом и его стандартной библиотекой, если проблема в stl, то ошибка должна уйти.

Ещё можно просто собрать шлангом и его стандартной библиотекой

Можно и без шланга, есть даже уже готовый скрипт g++-libc++, что флаги не выписывать.

Дык приходите и отлаживайте, я ж говорю - будем рады.

Чувствуется в Вас эдакий детский задор и отвага, давать радикальные советы по поводу кода которого в глаза не видели.

Вот здесь есть интересная фраза: If allocator_traits::construct is not supported with the appropriate arguments, it causes undefined behavior.

Дык приходите и отлаживайте, я ж говорю - будем рады.

Чувствуется в Вас эдакий детский задор и отвага, давать радикальные советы по поводу кода которого в глаза не видели.

О-о-о, намного профессиональнее размышлять какой лучше костыль воткнуть, а на действительно полезные советы звать делать за вас вашу работу. Расценки-то хоть озвучите?

Создай минимальный пример, который падает, и покажи.

Можно минимальный пример? И версию компилятора.

Косяк явно у вас где-то, а не в векторе. Где-то что-то портите. Тут помог бы минимальный код.

Так проблема не в контейнере. Ну и что, что несколько гигов? Это не так уж и много. Да и вообще, заходите багу, выделяйте время на исследования и пр. Что за говноподход к разработке?

Так а в корке что?

Покажите код, пожалуйста. Интересно.

О, я готов отдавать все что сам получаю - в данном конкретном случае одно большое человеческое спасибо в час.

Можно я сам буду оценивать какие советы для меня полезные а какие нет?

У меня на push_back ровно все то же самое.

по аватарке же видно всепропальщика, потому и скулит

Короче std::vector::emplace_back/push_back нестабильное гавно.

После перехода на std::list все норм. работает, а с этой фигней уже ЕМНИП второй раз напарываюсь - на тестах все ок, под нагрузкой сегфолтится или валится в деструкторе.

Компайлер g++ 4.8.2, на 4.7 в другом проекте были те же яйца.

Всем спасибо.

Действительно, чем искать откуда г...но всплывает, проще каждое всплывшее на якорь поставить. Инфа 146%.

Короче std::vector::emplace_back/push_back нестабильное гавно.

Нет ты.

99.9999%, что проблема в вашем коде. У нас тоже большие объёмы данных(наверное больше, чем у вас), std::vector часто используется, push_back/emplace_back тоже. На 4.8 жили довольно долго(тем более, что на 4.7 у вас тоже воспроизводится).

А почему вы не хотите разобраться?