Сколько лет работаю с визуал студио, часто наталкиваюсь на невозможность отловить некоторые баги. Скомпилил сервис, запускаю под дебагером, дебажный билд - работает прекрасно, никаких нареканий. Компилю релиз - вылазят эксепшны там, где их никогда не было, но релизную версию не подебажишь особо, чтобы исправить баги. Как вы с этим боретесь? От чего такая разница в работе?
НУ во первый настройки проекта. Во вторых ASSERT И одно из самых главных, что студия делает с переменными в дебаге? скомпилируйте и мод disassembly. Не которые детали Minidump + Settings -> generation assembly code (в лоб) Логи. SEH + C++ exception. И смотрите что за исключения. А вообще наверное надо читать ... ))
Соглашусь с Rel - бывает отличие из-за оптимизации (в дебаге нет оптимизации, в релизе обычно включена). nerd - попробуйте в своем релизе отключить оптимизацию,скомпилить - проверить, будут ли эксепшены вылазить...
ага, а толку никакого %) найти баг в своей проге - это не проблема. есть сорцы CRT\STL, есть хороший отладчик есть символы - можно дебажить хоть олькой можно вообще без отладчика - сделать логов вобщем это печально, что работая столько лет ТС не знает как найти баг. из за оптимизации ничего не бывает. бывает кривой код, который не соответствует тому что написано в стандарте или msdn.
ТС скачайте книжку Bugslayer'а Роббинс Дж. - Отладка приложений для Microsoft .NET и Microsoft Windows (2004)(14 Mb).djvu прилично по отладчику студийному написано как сделать отладку удобной да и вообще по отладке много всего
Дело в том что случай не совсем тривиальный: 1) Механизмом SEH в данном случае не удастся воспользоваться, отдельная тема. Если не найду простого решения, буду переделывать код чтобы можно было. 2) Ошибки трудновоспроизводимые - сервер обслуживает реальных пользователей, сервис по нескольку дней стабильно работает прежде чем что-то выдать. Вот смотрю, стек вызовов теряется где-то в диапазоне адресов не принадлежащем ни одному модулю, символов там нет. Там где символы есть дебагер не показывает значения большинства переменных в релизной конфигурации..
Как правило, ошибки инициализации и выход за пределы массивов. В debug версии выделяемая память инициализируется принудительно, в release - там мусор. В результате, ошибка случайна и невоспроизводима. Тщательное логгирование критических участков кода должно помочь. Как пример, при невозможности отладки (территориально удаленный клиент), я использовал такой подход: специальный билд имел встроенную трассировку (включалась условной компияляцией) всех критических участков, запись велась в кольцевой буфер (~ 256 Kb), при крэше этот буфер сбрасывался в файл и отсылался по эл.почте. Простенький вьювер сортировал записи из этого файла и строил дерево вызовов (типично, несколько сотен до крэша) с указанием значений логгируемых переменных. Большинство проблем решались уже на первой итерации.
Если стартую изначально под OllyDbg - сервис сразу падает. Подгружаю символы, но олли всё равно не в силах сказать где и что случилось, предлагает под дизассемблером рыться. В стеке вызовов нет даже имени моего модуля почему-то, только адреса.
Не хочу обидеть чьих-то религиозных чувств, задумка-то хорошая, но реализован Олли еще более глючно чем дебагер от MS. Как отлько аттачу олли к сервису, сервис сразу перестает работать (хотя олли пишет Running), и сам олли подгружает процессор на 80%. Возможно из-за моих потуг по реализации SEH.
интересно, почему у многих людей не возникает проблем ни с олли, ни с виндбг, ни с отладчиком студии, а у вас возникают?)
А есть сопровождающий сиди для второго издания, а то я что-то найти не могу.... Интересно, почему не выложить исходники вместе с книгой? Звучит довольно разумно....
