Здравствуйте, Melamed, Вы писали:
M>Привет M>Я написал программу. В Debug-версии программы все работает нормально. Начал готовить программу сдачи. Сделал Reliase версию моей программы и на одном из тестов она стала падать. Провел тот же тест с Debager-версии, программа работает нормально.
Здравствуйте, Melamed, Вы писали:
M>Привет M>Я написал программу. В Debug-версии программы все работает нормально. Начал готовить программу сдачи. Сделал Reliase версию моей программы и на одном из тестов она стала падать. Провел тот же тест с Debager-версии, программа работает нормально.
M>Выдает ошибку nhandled exception at at 0x75A3C42D in ConvertArchiv.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x10DFF090.
M>По внешним признакам ошибка происходит в довольно объемной процедуре. Нужно локализовать ошибку и принять решение об исправлении ошибки.
M>Среда обработки MSVS 2012 C++ голый win API + библиотека ZipArchive
делай релиз сборку с включенной генерацией дебаг информации
Если штатные средства студии не помогают, попробуй внешние анализаторы типа dr. memory http://www.drmemory.org/
Обрати внимание на чтение неинициализированных данных — это прямое указание на то, что у тебя что-то имеет нестабильное стартовое состояние.
Здравствуйте, Melamed, Вы писали:
M>Выдает ошибку nhandled exception at at 0x75A3C42D in ConvertArchiv.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x10DFF090.
M>По внешним признакам ошибка происходит в довольно объемной процедуре. Нужно локализовать ошибку и принять решение об исправлении ошибки.
Здравствуйте, Melamed, Вы писали:
M>Привет M>Я написал программу. В Debug-версии программы все работает нормально. Начал готовить программу сдачи. Сделал Reliase версию моей программы и на одном из тестов она стала падать. Провел тот же тест с Debager-версии, программа работает нормально.
M>Выдает ошибку nhandled exception at at 0x75A3C42D in ConvertArchiv.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x10DFF090.
M>По внешним признакам ошибка происходит в довольно объемной процедуре. Нужно локализовать ошибку и принять решение об исправлении ошибки.
M>Среда обработки MSVS 2012 C++ голый win API + библиотека ZipArchive
* Отладка Release (как уже порекомендовали, включить debug info)
* Повставлять логи
Привет
Я написал программу. В Debug-версии программы все работает нормально. Начал готовить программу сдачи. Сделал Reliase версию моей программы и на одном из тестов она стала падать. Провел тот же тест с Debager-версии, программа работает нормально.
Выдает ошибку nhandled exception at at 0x75A3C42D in ConvertArchiv.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x10DFF090.
По внешним признакам ошибка происходит в довольно объемной процедуре. Нужно локализовать ошибку и принять решение об исправлении ошибки.
Среда обработки MSVS 2012 C++ голый win API + библиотека ZipArchive
Здравствуйте, Melamed, Вы писали:
M>Привет M>Я написал программу. В Debug-версии программы все работает нормально. Начал готовить программу сдачи. Сделал Reliase версию моей программы и на одном из тестов она стала падать. Провел тот же тест с Debager-версии, программа работает нормально.
M>Выдает ошибку nhandled exception at at 0x75A3C42D in ConvertArchiv.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x10DFF090.
M>По внешним признакам ошибка происходит в довольно объемной процедуре. Нужно локализовать ошибку и принять решение об исправлении ошибки.
M>Среда обработки MSVS 2012 C++ голый win API + библиотека ZipArchive
1. Посмотреть наличие #ifdef DEBUG
2. Разбить процедуру на более мелкие. Может и ошибку в процессе найдете
3. cout<<("line 1\n");
Здравствуйте, Melamed, Вы писали:
M>Привет M>Среда обработки MSVS 2012 C++ голый win API + библиотека ZipArchive
Искать баг в дебажной, обратить внимание на многопточность и на утечки памяти.
Sic luceat lux!
Re[2]: Как поймать глюк в Release версии программы
Подобное случалось у меня неоднократно. 90% что выходите за границу массива или ездиете по невыделенной памяти каким-то образом, что не мешает в Debug-версии так-как перезаписываете просто отладочную информацию. Особенно учитывая сообщение exceptionа.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Melamed, Вы писали:
M>Привет M>Я написал программу. В Debug-версии программы все работает нормально. Начал готовить программу сдачи. Сделал Reliase версию моей программы и на одном из тестов она стала падать. Провел тот же тест с Debager-версии, программа работает нормально.
Для этой цели применяем вывод информации в файл *.log.
M>Выдает ошибку nhandled exception at at 0x75A3C42D in ConvertArchiv.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x10DFF090.
Ставить вывод в файл *.log — в тех местах, где есть подозрение на проблему (выделение памяти, работа с массивами).
M>По внешним признакам ошибка происходит в довольно объемной процедуре. Нужно локализовать ошибку и принять решение об исправлении ошибки.
Если, например, имеется процедура: MyFoo то ставим логи внутри процедуры: MyFoo_1, MyFoo_2 и т.д.
В таких логах делаю вывод переменны (указатели, индексы массивов) — которые могут посодействовать решению проблемы.
M>Среда обработки MSVS 2012 C++ голый win API + библиотека ZipArchive
Применяем логирование в наших разработках на MFC и WinAPI (конкретно с ZipArchive не работал).
Здравствуйте, Melamed, Вы писали:
M>Привет M>Я написал программу. В Debug-версии программы все работает нормально. Начал готовить программу сдачи. Сделал Reliase версию моей программы и на одном из тестов она стала падать. Провел тот же тест с Debager-версии, программа работает нормально.
используй инструменты по поиску проблем с памятью для начала. Так есть много методов, начиная с пряморукого программирования, но в данном случае они преждевременны (или уже опоздали, как в случае с пряморуким программированием)
Здравствуйте, Melamed, Вы писали:
M>Выдает ошибку nhandled exception at at 0x75A3C42D in ConvertArchiv.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x10DFF090.
Самое простое — посмотреть в диспетчере задач на расход памяти. Может быть, релизная версия реально её жрёт.
Если да — смотреть, почему.
Если нет — значит, кто-то расстрелял кучу.
Жрать можно по-разным причинам.
1) Нюансы алгоритма.
Например, если многопоточное приложение в режиме producer-consumer — в дебаге работает, как пинг-понг: послал-принял-послал-принял, а в релизе другая временная диаграмма, вплоть до блокировки потока-потребителя, и вышло послал-послал-послал...
2) Мусор на входе. Неинициализированная или неправильно инициализированная переменная, которая влияет на размер выделяемых данных.
size_t xz;
vector<int> v;
v.reserve(xz); // ошибку даже не сразу в отладчике заметишь, ибо IDE показывает размер, а не резерв массиваint wtf;
while(wtf > 0) v.push_back(wtf); // особенно весело для отрицательных чисел
3) Разные размеры структур данных — влияющие на выбор той или иной ветки кода
struct FOO {
int x;
int y;
#ifdef DEBUG
int z;
#endif
};
struct BAR {
unsigned int x;
unsigned int y;
unsigned int z;
};
...
if(sizeof(FOO) == sizeof(BAR))
milota();
else
drei_hundert_teuffelen(); // мы это не отлаживали
или, что более граблисто,
template<class It> void process_iterated_item(It) { milota(); } // мы отлаживали только этоtemplate<class T> void process_iterated_item(T*) { red_alert(); }
void process_iterated_item(const char*) { treat_as_null_terminated_string(); } // а это вызывали вообще в других случаях
vector<int> v;
vector<char> s;
...
process_iterated_item(v.begin());
process_iterated_item(s.begin());
Ну а расстрелять память — это вообще тысячи способов.
Здравствуйте, Melamed, Вы писали:
M>Привет M>Я написал программу. В Debug-версии программы все работает нормально. Начал готовить программу сдачи. Сделал Reliase версию моей программы и на одном из тестов она стала падать. Провел тот же тест с Debager-версии, программа работает нормально.
M>Выдает ошибку nhandled exception at at 0x75A3C42D in ConvertArchiv.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x10DFF090.
M>По внешним признакам ошибка происходит в довольно объемной процедуре. Нужно локализовать ошибку и принять решение об исправлении ошибки.
M>Среда обработки MSVS 2012 C++ голый win API + библиотека ZipArchive
А вот я однажды в MSVC-2003 именно в релизе поймал глюк, который никто не смог объяснить порчей памяти или неинициализированными переменными.
Я долго пытался понять, почему объект создаётся корректно, а сразу после передачи в другую функцию объект превращался в груду мусора. Я нашёл место, где происходит что-то странное, внимательно изучил асмовыхлоп... Короче, суть в том, что компилятор насоздавал на стеке временных объектов, повызывал их методы, а потом в другую функцию кинул ссылку на этот временный объект, но с неправильным смещением относительно верхушки стека (ну то есть типа записал в регистр esp-12 вместо esp-8, как-то так).
У меня даже асмокод где-то сохранился.
Мне сказали, что такое бывает.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Константин, Вы писали:
Z>>>делай релиз сборку с включенной генерацией дебаг информации C>>и отключи оптимизацию К>Зачем? Обычно и без этого нормально всё отлаживается
не всегда. к примеру, может стек быть разбит.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Перекуём баги на фичи!
