Всем привет.
Возникла такая проблема.
Есть приложение которое открывает файлы, процессит их, и закрывает.
Так вот в ходе процессинга переодически возникает исключение bad_alloc
которое местами можно перехватить а местами (внутри библиотеки QT) неззя.
Исключение рандомное — на рандомных файлах бывает редко но бывает.
В том числе происходит при попытке создать обыкновенный класс без внутренних наворотов.
Собственно вопрос — что может быть причиной того что валидные операторы new вызывают std::bad_alloc ?
Дополнительная информация:
1) в приложении используются сторонние библиотеки которые не исключено могут портить память
но вот я не очень пойму что такого должно быть испорчено в памяти чтобы апликуха вылетала с невозможностью выделить память.
2) библиотека которая может портить память использует CRT 5-й версии (линукс) а сама апликуха 6-ю
3) если скипать эти бедаллоки — то все работает нормально
4) аппликуха отжирает всего 200 метров памяти из 3х гигабайт
5) иногда так же само падает QT — но тут уже не перехватишь исключение.
ИМХО тут дебагером только смотреть надо.
Может быть всё угодно от фрагментации памяти, неправильного размера выделяемой памяти (например переполнение где то или что то такое), до кривого самопального алокатора (если такой используется).
Здравствуйте, nen777w, Вы писали:
N>ИМХО тут дебагером только смотреть надо. N>Может быть всё угодно от фрагментации памяти, неправильного размера выделяемой памяти (например переполнение где то или что то такое), до кривого самопального алокатора (если такой используется).
вот дебагером то не посмотришь.
так как эксепшин после 15-ти минут работы в среднем
и когда он отлавливается — то встек то уже раскручен.
ставить бряку на все экспешины бесполезно так как используется модель возврата ошибки по экспешину а не по коду возврата.
кстати вот вариант когда кучу смешали с г-ном
2) библиотека которая может портить память использует CRT 5-й версии (линукс) а сама апликуха 6-ю
недавно боролся с подобным. только там рушилось сразу (под дебагом конечно это было видно). Выделяли память в одной CRT а освобождали в другой.
Dez>ставить бряку на все экспешины бесполезно так как используется модель возврата ошибки по экспешину а не по коду возврата.
А зачем на все эксепшены. Если в студии работаете то в Debug->Exceptions... C++Exceptions->std::exception
Или ваши исключение тоже от std::exception унаследованы?
Здравствуйте, nen777w, Вы писали:
Dez>>ставить бряку на все экспешины бесполезно так как используется модель возврата ошибки по экспешину а не по коду возврата.
N>А зачем на все эксепшены. Если в студии работаете то в Debug->Exceptions... C++Exceptions->std::exception N>Или ваши исключение тоже от std::exception унаследованы?
бага повторяется только под линуксом
а там только бряка на все эксепшины — или я не прав ?
Здравствуйте, Dez, Вы писали:
Dez>Собственно вопрос — что может быть причиной того что валидные операторы new вызывают std::bad_alloc ?
например, выделение слишком больших кусков памяти (>4 гигабайта). бывает при использовании неинициализированных переменных
рекомендации:
1) проверить crash dump
2) использовать valgrind
3) проверить (r)limits
Типичный баг, по крайней мере под виндой
чтобы вылетел бэдаллок не нужно портить память, или отжирать ее. Вполне достаточно в 2ГБ адресное пространство загрузить 50 дллек, которые порубят его на непрерывные куски по 40мб +-
Здравствуйте, Dez, Вы писали:
Dez>вот дебагером то не посмотришь. Dez>так как эксепшин после 15-ти минут работы в среднем Dez>и когда он отлавливается — то встек то уже раскручен.
Дык не перехватывай его вообще нигде.
В результате твое приложение завершится аварийно, при этом стек раскручен не будет.
Можно будет посмотреть бэктрейс.
Здравствуйте, rm822, Вы писали:
R>Типичный баг, по крайней мере под виндой R>чтобы вылетел бэдаллок не нужно портить память, или отжирать ее. Вполне достаточно в 2ГБ адресное пространство загрузить 50 дллек, которые порубят его на непрерывные куски по 40мб +-
Ваш ответ подтолкнул к поиску ошибки.
Оказалось что в программе есть утечки памяти (около 100-200 МБ) в принципе не критичных, но их много и судя по всему они сильно фрагментировали память что собственно иногда не позволяло выделить цельный блок нужного размера.
Полечив утечки вылечились и креши.
