LINUX.ORG.RU

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

 ,


1

5

Сабж.

Валится при size()==16.

Валится редко, но достаточно одного раза.

Переписал сначала добавление элементов в std::list, затем для вектора resize и копирование из списка - все работает.

Но вообще то это странный косяк... кто нить сталкивался?

★★★★★

Последнее исправление: AIv (всего исправлений: 1)

версию gcc.

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

anonymous
()

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

gavlig ★★★
()

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

Iron_Bug ★★★★★
()

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

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

Kroz ★★★★★
()
Ответ на: комментарий от x0r

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от monk

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

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

AIv ★★★★★
() автор топика

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

anonymous
()
Ответ на: комментарий от Kroz

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

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

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

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

anonymous
()
Ответ на: комментарий от AIv

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от AIv

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от AIv

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

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

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

one_more_hokum ★★★
()
Ответ на: комментарий от one_more_hokum

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

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

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

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

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

O02eg ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

x0r ★★★★★
()
Ответ на: комментарий от AIv

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от O02eg

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

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от AIv

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

O02eg ★★★★★
()
Ответ на: комментарий от O02eg

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

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

anonymous
()
Ответ на: комментарий от Iron_Bug

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

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

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

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

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

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

slovazap ★★★★★
()

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

anonymous
()
Ответ на: комментарий от x0r

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

anonymous
()
Ответ на: комментарий от AIv

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

anonymous
()
Ответ на: комментарий от AIv

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

anonymous
()
Ответ на: комментарий от x0r

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

anonymous
()
Ответ на: комментарий от slovazap

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

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

AIv ★★★★★
() автор топика
Ответ на: комментарий от x0r

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

AIv ★★★★★
() автор топика
Ответ на: комментарий от Iron_Bug

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

anonymous
()
Ответ на: комментарий от x0r

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

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

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

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

AIv ★★★★★
() автор топика
Ответ на: комментарий от AIv

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

anonymous
()
Ответ на: комментарий от AIv

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.