что такое дебаг версия

Урок №6. Режимы конфигурации «Debug» и «Release»

Конфигурация сборки (англ. «build configuration») — это набор настроек проекта, которые определяют принцип его построения. Конфигурация сборки состоит из:

имени исполняемого файла;

имени директории исполняемого файла;

имён директорий, в которых IDE будет искать другой код и файлы библиотек;

информации об отладке и параметрах оптимизации вашего проекта.

Интегрированная среда разработки имеет две конфигурации сборки: «Debug» (Отладка) и «Release» (Релиз).

Конфигурация «Debug» предназначена для отладки вашей программы. Эта конфигурация отключает все настройки по оптимизации, включает информацию об отладке, что делает ваши программы больше и медленнее, но упрощает проведение отладки. Режим «Debug» обычно используется в качестве конфигурации по умолчанию.

Конфигурация «Release» используется во время сборки программы для её дальнейшего выпуска. Программа оптимизируется по размеру и производительности и не содержит дополнительную информацию об отладке.

Например, исполняемый файл программы «Hello, World!» из предыдущего урока, созданный в конфигурации «Debug», у меня занимал 65 КБ, в то время как исполняемый файл, построенный в конфигурации «Release», занимал всего лишь 12 КБ.

Переключение между режимами «Debug» и «Release» в Visual Studio

Самый простой способ изменить конфигурацию проекта — выбрать соответствующую из выпадающего списка на панели быстрого доступа:

Переключение между режимами «Debug» и «Release» в Code::Blocks

В Code::Blocks на панели быстрого доступа есть также выпадающий список, где вы можете выбрать соответствующий режим конфигурации:

Заключение

Используйте конфигурацию «Debug» при разработке программ, а конфигурацию «Release» при их релизе.

Поделиться в социальных сетях:

Урок №5. Компиляция вашей первой программы

Комментариев: 16

Здравствуйте. Спасибо, отличный курс.
Вопрос. Как реализовать режим Release в командной строке, используя Mingw?
Успехов. Еще раз Спасибо

Источник

Пара историй про отличия Release от Debug

Все разработчики знают, что исполнение релизной версии может отличаться от отладочной. В этой статье я расскажу пару случаев из жизни, когда такие отличия приводили к ошибочному исполнению программы. Примеры не отличаются большой сложностью, но вполне могут уберечь от наступления на грабли.

История 1

Собственно, началось все с того, что пришел баг о том что при некоторых операциях приложение вылетает. Это бывает часто. Баг не захотел воспроизводиться в Debug-версии. Это порой бывает. Поскольку в приложении часть библиотек была написано на C++, то первой мыслью было что-то вроде «где-то забыли переменную проинициализировать или что-то в этом духе». Но на деле суть бага крылась в управляемом коде, хотя без неуправляемого тоже не обошлось.

А код оказался примерно следующим:

protected virtual void Dispose( bool disposing)
<
if (disposing)
<
>

В принципе, практически каноническая реализация шаблона IDisposable («практически» — потому, что нет переменной disposed, вместо нее обнуление указателя), вполне стандартный класс-обертка неуправляемого ресурса.

Использовался же класс примерно следующим образом:

Естественно, что внимательный читатель сразу обратит внимание, что объекта wr надо вызвать Dispose, то есть обернуть все конструкцией using. Но на первый взгляд, на причину падения это не должно повлиять, так как разница будет в том детерминировано ли очистится ресурс или нет.

Но на самом деле разница есть и именно в релизной сборке. Дело в том, что объект wr становится доступным сборщику мусора сразу после начала выполнения метода DoCalculations, ведь больше нет ни одного «живого» объекта, кто на него ссылался бы. А значит wr вполне может(а так оно и происходило) быть уничтожен во время выполнения DoCalculations и указатель, переданный в этот метод становится невалидным.

Если обернуть вызов DoCalculations в using (Wrapper wr = new Wrapper())<. >, то это решит проблему, поскольку вызов Dispose в блоке finally, не даст жадному сборщику мусора «съесть» объект раньше времени. Если же по какой-то причине мы не можем или не хотим вызывать Dispose (к примеру WPF этот шаблон совсем не жалует), то придется вставлять GC.KeepAlive(wr) после вызова DoCalculations.

Реальный код, безусловно, был сложнее и разглядеть в нем ошибку было не так просто, как в примере.

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

История 2

Жил-был проект, где для доступа к ресурсам использовался менеджер, который по строковому ключу доставал из заданной сборки различного вида ресурсы. С целью облегчения написания кода был написан следующего вида метод:

Чтобы «почувствовать разницу» предлагается следующий пример:

public void Method22()
<
( new Class1()).Method1();
>
>

dll3:
class Program
<
static void Main( string [] args)
<
( new Class3()).Method3();
>
>
class Class3
<
public void Method3()
<
( new Class2()).Method21();
>
>

Если скомпилировать в дебажной конфигурации(или если запускать процесс из-под студии) то получим честный стек вызовов:
в ClassLibrary1.Class1.Method1()
в ClassLibrary2.Class2.Method22()
в ClassLibrary2.Class2.Method21()
в ConsoleApplication1.Class3.Method3()
в ConsoleApplication1.Program.Main(String[] args)

Мораль здесь проста — не стоит привязывать логику к стеку вызовов, равно как и удивляться необычному стеку в исключениях в логе релизной версии. В частности, если вы пытаетесь найти причину исключения исключительно по его стеку вызовов, то стоит учитывать, что если стек заканчивается на методе Method1, то в коде оно(исключение) могло быть сгенерировано в одном из небольших методов, которые вызываются в теле Method1.

Так же на всякий случай стоит помнить, что можно запретить компилятору встраивать метод пометив его атрибутом [MethodImpl(MethodImplOptions.NoInlining)], эдакий аналог __declspec(noinline) в VC++.

Вместо заключения

Мир проявляемых только в релизе багов воистину безграничен, и цели сделать полный его обзор я не ставил. Просто хотелось поделиться собственным опытом, точнее более интересной его частью. Ну и остается только пожелать читателям поменьше сталкиваться с подобными ошибками в работе.

Источник

Отладка как процесс

Существует мнение, что разработка занимает около 10% времени, а отладка — 90%. Возможно, это утверждение утрировано, но любой разработчик согласится с тем, что отладка — крайне затратный по ресурсам процесс, особенно в больших многопоточных системах.

Таким образом, оптимизация и систематизация процесса debugging’а может приносить весомые плоды в виде сэкономленных человеко-часов, повышения скорости решения проблем и, в конце концов, увеличения лояльности ваших пользователей.

Сергей Щегрикович (dotmailer) на конференции DotNext 2018 Piter предложил взглянуть на отладку как на процесс, который может быть описан и оптимизирован. Если вы до сих пор не имеете четкого плана поиска багов — под катом видео и текстовая расшифровка доклада Сергея.

(А еще в конце поста мы добавили обращение Джона Скита ко всем дотнетчикам, обязательно посмотрите)

Моя цель — ответить на вопрос: как фиксить баги эффективно и на чем должен быть фокус. Я думаю, что ответ на этот вопрос — процесс. Процесс debugging’а, который состоит из очень простых правил, и вы хорошо их знаете, но, наверно, используете неосознанно. Поэтому моя задача — это систематизировать их и на примере показать как стать более эффективными.

Мы выработаем общий язык общения во время отладки, а также увидим прямой путь к поиску основных проблем. На своих примерах я покажу что получалось из-за нарушения этих правил.

Утилиты отладки

Конечно, любой debugging невозможен без утилит для отладки. Моими любимыми являются:

Падающий сервис

Начнем с примера из моей жизни, в котором я покажу, как бессистемность процесса debugging’а ведет к неэффективности.

Наверно, у каждого такое бывало, когда ты приходишь в новую компанию в новую команду на новый проект, то с самого первого дня хочется нанести непоправимую пользу. Так было и у меня. В то время у нас был сервис, который на вход принимал html, а на выход выдавал картинки.

Сервис был для нас не критичен и мы могли это пережить. Но к проекту подключился я и первое, что решил сделать — исправить это.

Компилируем, деплоим, сервис падает, ошибок нет. За этим процессом проходит три дня, теперь уже приходят мысли о том, что надо наконец-то начать думать и делать что-нибудь другое. Делать можно много чего: попробовать воспроизвести ошибку на локальной машине, смотреть дампы памяти и тд. Казалось, еще дня два и я пофикшу этот баг…

Я смотрел в PerformanceMonitor, где видел сервис, который падает, потом поднимается, потом снова падает. Это состояние называется отчаяние и выглядит вот так:

В этом разнообразии меток ты пытаешься понять, где же на самом деле проблема? После нескольких часов медитации проблема вдруг обнаруживается:

Красная линия — это количество нативных handle’ов, которыми владеет процесс. Нативный handle — это ссылка на ресурс операционной системы: файл, реестр, ключ реестра, мьютекс и тд. По какому-то непонятному стечению обстоятельств падение роста количества handle’ов совпадает с моментами падения сервиса. Это наталкивает на мысль о том, что где-то есть утечка handle’ов.

Берем дамп памяти, открываем его в WinDbg. Начинаем выполнять команды. Попробуем посмотреть очередь финализации тех объектов, которые должны быть освобождены приложением.

В самом конце списка я нашел web-браузер.

Решение простое — взять WebBrowser и вызывать для него dispose :

Выводы из этой истории можно сделать такие: две недели — это долго и слишком много, чтобы найти невызванный dispose ; то, что мы нашли решение проблемы — везение, так как не было какого-то определенного подхода, не было системности.

После этого у меня возник вопрос: а как дебажить эффективно и что для этого делать?

Для этого надо знать всего три вещи:

Правила отладки

Повтори ошибку. Очень простое правило, поскольку, если ты не можешь повторить ошибку, то, возможно, и фиксить нечего. Но бывают разные случаи, особенно это касается багов в многопоточной среде. У нас как-то была ошибка, которая появлялась только на процессорах Itanium и только на продакшн-серверах. Поэтому первая задача в процессе отладки — найти такую конфигурации тестового стенда, на которой бы ошибка воспроизводилась.

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

Пойми систему. Брайан Керниган сказал как-то, что если мы были такие умные, чтобы написать эту систему, то нам нужно быть вдвойне умными, чтобы её дебажить.

Небольшой пример к правилу. Наш мониторинг рисует графики:

Это график количества запросов, обработанных нашим сервисом. Однажды посмотрев на него мы пришли к идеи о том, что можно было бы увеличить скорость работы сервиса. В этом случае график поднимется, возможно, удастся уменьшить количество серверов.

Оптимизация web-performance делается просто: берем PerfView, запускаем его на продакшн-машине, он снимает trace в течении 3-4 минут, мы этот trace забираем на локальную машину и начинаем его изучать.

Одна из статистик, которую показывает PerfView — garbage collector.

Посмотрев на эту статистику мы увидели, что 85% времени сервис тратит на сборку мусора. Можно в PerfView увидеть где конкретно тратится это время.

В нашем случае — это создание строк. Исправление напрашивается само самой: заменяем все string’и на StringBuilder’ы. Локально получаем прирост производительности на 20-30%. Деплоим на продакшн, смотрим результаты в сравнении со старым графиком:

Правило «Пойми систему» — это не только о том, чтобы понять как в вашей системе происходят взаимодействия, как ходят сообщения, а о том, чтобы попробовать смоделировать свою систему.

В примере график показывает пропускную способность. Но если посмотреть на всю систему с точки зрения теории очередей, то окажется, что пропускная способность нашей системы зависит только от одного параметра — от скорости прихода новых сообщений. По факту в системе просто не было больше 80 сообщений единовременно, поэтому оптимизировать этот график не получится никак.

Проверь штепсель. Если открыть документацию любого домашнего прибора, то там обязательно будет написано: если прибор не работает, проверь, что вилка вставлена в розетку. После нескольких часов в отладчике часто ловлю себя на мысли, что надо было просто перекомпилировать, либо просто забрать последнюю версию.

Правило «проверь штепсель» — это про факты и данные. Отладка не начинается с запуска WinDbg или PerfView на продакшн-машинах, она начинается с проверок фактов и данных. Если сервис не отвечает, возможно он просто не запущен.

Разделяй и властвуй. Это первое и, наверно, единственное правило, которое включает в себя отладку как процесс. Оно про гипотезы, их выдвижение и проверку.

Один из наших сервисов не хотел останавливаться.

Делаем гипотезу: возможно, в проекте есть цикл, который бесконечно что-то обрабатывает.

Проверить гипотезу можно по-разному, один из вариантов — это взять дамп памяти. Из дампа вытаскиваем call-stack’и всех потоков с помощью команды

Делаем вторую гипотезу: возможно, у нас deadlock одной задачи на вторую. Чтобы это проверить, можно через WinDbg посмотреть каждую задачу по-отдельности.

Оказывается, одна из задач упала, а вторая — нет. В проекте мы увидели такой код:

Он означает, что инициализационная задача открывает connection и после этого выставляет TaskCompletionSource в true. А что, если здесь упадет Exception? Тогда мы не успеваем выставить SetResult в true, поэтому fix к этому багу был такой:

В этом примере мы выдвигали две гипотезы: о бесконечном цикле и о deadlock’e. Правило «разделяй и властвуй» помогает локализовать ошибку. Последовательными приближениями и решаются такие проблемы.

Самое важное в этом правиле — это гипотезы, поскольку со временем они превращаются в паттерны. И в зависимости от гипотезы мы применяем разные действия.

Освежись. Это правило о том, что надо просто встать из-за стола и пройтись, выпить воды, сока или кофе, сделать что угодно, но самое главное — отвлечься от своей проблемы.

Есть очень хороший метод под названием «уточка». Согласно методу мы должны рассказать о своей проблеме уточке. В качестве уточки можно использовать коллегу. Причем, ему не обязательно отвечать, достаточно слушать и соглашаться. И зачастую, после первых проговоров проблемы, ты сам находишь решение.

Это твой баг. Об этом правиле расскажу на примере.

Для меня это вылилось в 11 месяцев работы с поддержкой Microsoft, конечно, не ежедневно, но от начала до fix’а прошло именно 11 месяцев. Кроме этого, мы отправили им десятки гигабайт дампов памяти, мы ставили сотни private-сборок, чтобы поймать эту ошибку. И все это время мы не могли сказать нашим клиентам, что виновата Microsoft, а не мы. Поэтому баг всегда ваш.

Пять почему. Мы у себя в компании используем Elastic. Elastic хорош для агрегации логов.

Ты приходишь с утра на работу, а Elastic лежит.

Вопросы «почему?» помогают найти корень проблемы. В примере мы много раз могли свернуть с правильного пути, но полный fix выглядит так: обновляем плагин, запускаем сервисы, наращиваем память и делаем пометку на будущее, что в следующий раз, при добавлении новых узлов в кластер, нужно убедиться в достаточности памяти на Master Nodes.

Алгоритм отладки

Впервые про алгоритм отладки я прочитал в книге Джона Роббинса «Debugging applications». Он описывает процесс отладки так:

Этот алгоритм полезен своим внутренним циклом — работой с гипотезой.

С каждым витком цикла мы можем себя проверить: знаем ли мы больше о системе или нет? Если мы выдвигаем гипотезы, проверяем, они не срабатывают, мы не узнаем ничего нового о работе системы, то, наверно, пора освежиться. Два актуальных вопроса на этот момент: какие гипотезы ты уже проверил и какую гипотезу проверяешь сейчас.

Этот алгоритм очень хорошо согласуется с правилами отладки, о которых мы говорили выше: повтори ошибку — это твой баг, опиши проблему — пойми систему, сформулируй гипотезу — разделяй и властвуй, проверь гипотезу — проверь штепсель, убедись что исправлено — пять почему.

На этот алгоритм у меня есть хороший пример. На одном из наших web-сервисов падал exception.

Первая наша мысль — это не наша проблема. Но по правилам, это все-таки проблема наша.

Во-вторых, пытаемся описать проблему: если пользователь делает http-запрос на наш сервис в момент, когда StructureMap пытается сделать новую зависимость, то в этом случае происходит исключение.

В-третьих, выдвигаем гипотезу о том, что StructureMap — это wrapper и внутри что-то есть, что кидает внутреннее исключение. Проверяем гипотезу с помощью procdump.exe.

Исследуя call-stack этого исключения понимаем, что оно происходит внутри object-builder’а в самом StructureMap.

Но NullReferenceException — это не сама проблема, а следствие. Нужно понять где оно возникает и кто его генерирует.

Итак, алгоритм отладки — это интуитивный алгоритм, который существенно экономит время. Он делает упор на гипотезу — а это самое главное в отладке.

Проактивная отладка

По своей сути проактивная отладка отвечает на вопрос «что произойдет, когда появится баг».

Важность техники проактивной отладки можно увидеть на диаграмме цикла жизни бага.

Проблема в том, что чем дольше баг живет, тем больше мы ресурсов (времени) на него тратим.

Правила отладки и алгоритм отладки фокусируют нас на моменте, когда баг найден и мы можем придумать что дальше с ним делать. На самом же деле мы хотим сместить свой фокус на момент создания бага. Я считаю, что мы должны делать Minimum Debuggable Product (MDP), то есть такой продукт, который имеет минимально необходимый набор инфраструктуры для эффективной отладки в продакшене.

MDP состоит из двух вещей: фитнес-функции и USE метода.

Фитнес-функции. Были популяризированы Нил Фордом и соавторами в книге «Building Evolutionary Architectures ». По своей сути фитнес-функции, по мнению авторов книги, выглядят так: есть архитектура приложения, которую мы можем разрезать под разными углами, получая такие свойства архитектуры, как maintainability, performance и прочее, и на каждый такой разрез мы должны писать тест — фитнес-функцию. Таким образом, фитнес-функция — это тест на архитектуру.

В случае MDP, фитнес-функция — это проверка debuggability. Для написания таких тестов можно использовать все что угодно: NUnit, MSTest и тд. Но, поскольку, отладка — это, зачастую, работа с внешними tool’ами, я покажу на примере использование Pester’а (powershell unit testing framework). Его плюс здесь в том, что он хорошо работает с командной строкой.

Например, внутри компании мы договариваемся, что будем использовать конкретные библиотеки для логирования; при логировании мы будем использовать конкретные паттерны; pdb-символы должны быть отданы всегда на symbol server. Это и будет являться теми условностями, которые мы будем проверять в наших тестах.

Этот тест проверяет, что все pdb-символы были отданы на symbol server и были отданы правильно, то есть те, которые содержат номера строк внутри. Для этого берем скомпилированную версию продакшена, находим все exe- и dll-файлы, пропускаем все эти бинарники через утилиту syschk.exe, которая входит в пакет «Debugging tools for windows». Утилита syschk.exe сверяет бинарник с symbol server’ом и, если находит там pdb-файл, печатает отчет об этом. В отчете мы ищем строку «Line numbers: TRUE». И в финале проверяем, чтобы результат был не «null or empty».

Такие тесты необходимо встраивать в continuous deployment pipeline. После того, как прошли интеграционные тесты и unit-тесты, запускаются фитнес-функции.

Покажу ещё один пример с проверкой нужных библиотек в коде.

В тесте мы берем все файлы packages.config и пытаемся найти в них библиотеки nlog. Аналогично мы можем проверить, что внутри поля nlog используется поле correlation id.

USE методы. Последнее, из чего состоит MDP — это метрики, которые нужно собирать.

Продемонстрирую на примере метода USE, который был популяризирован Бренданом Греггом. Идея простая: если в коде есть какая-то проблема, достаточно взять три метрики: utilization (использование), saturation (насыщение), errors (ошибки), которые помогут осознать где проблема.

Некоторые компании, например Circonus (они делают monitoring soft), свои дашборды выстраивают в виде обозначенных метрик.

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

Если взять какую-нибудь бизнес-фичу, то, скорее всего, в ней можно выделить три метрики:

Первая гипотеза, которую мы сделали, — сервис упал и надо его запустить заново. При проверке оказывается, что сервис работает, использует 4-5% CPU.

Вторая гипотеза — внутри сервиса падает ошибка, которую мы не видим. Воспользуемся утилитой etrace.

Утилита позволяет в realtime подписываться к ETW-events и выводить их на экран.

Следующая гипотеза — кто-то съедает всю память. Согласно дампу памяти, больше всего объектов находится в кэше.

Из кода видно, что каждый час кэш должен очищаться. Но памяти уже не хватало, до очистки даже не доходили. Посмотрим на пример метрики USE для кеша.

По графику сразу видно — возросла память, сразу начались ошибки.

Итак, выводы о том, что же такое проактивная отладка.

Итак, как фиксить баги эффективно?

Источник

Debug

Debug — Программа-отладчик, которую используют для проверки и отладки выполняемых файлов. Использовалась при операционной системе MS-DOS. Под более поздние версии операционных систем работает через эмулятор MS-DOS и имеет ограниченные возможности.

Содержание

Назначение

Данная программа является консольным приложением и предназначена для создания или изменения кода файлов. С помощью неё можно создавать простые приложение под MS-DOS и отслеживать их работу. Данный отладчик находится на самом низком уровне компиляторов assembler. Но обладает неплохими возможностями такими как просмотр, изменение памяти и получение состояния регистров.

Команды

Запуск отладчика

Программа вызывается через командную строку:

Работа с файлами

Отображение и изменение значений регистров

Дамп памяти

Дизассемблирование

Ассемблирование

Компиляция

Трассировка

См. также

Примечания

Ссылки

Список команд DOS • Список команд операционных систем Miscrosoft

Полезное

Смотреть что такое «Debug» в других словарях:

Debug — ([ˌdiːˈbʌg]) steht für: den Vorgang des Debuggens, siehe Debugger De:Bug, eine Zeitschrift, siehe DeBug DEBUG.EXE, der Microsoft DOS Debug Editor … Deutsch Wikipedia

debug — de‧bug [ˌdiːˈbʌg] verb debugged PTandPPX debugging PRESPARTX [transitive] COMPUTING to remove bug S (= faults ) from a computer program … Financial and business terms

debug — 1945, of machine systems, from DE (Cf. de ) + BUG (Cf. bug) glitch, defect in a machine. Meaning to remove a concealed microphone is from 1964 … Etymology dictionary

debug — [v] troubleshoot adjust, correct, fix, iron out, remedy, remove errors, repair, sort out, straighten out, unravel, unscramble, untangle, work the bugs out of; concepts 126,212 … New thesaurus

debug — ► VERB (debugged, debugging) ▪ remove errors from (computer hardware or software). DERIVATIVES debugger noun … English terms dictionary

debug — [dē bug′] vt. debugged, debugging [ DE + BUG1] 1. to remove insects from 2. to find and correct the defects, errors, malfunctioning parts, etc. in 3. Informal to find and remove hidden electronic listening devices from (a place) … English World dictionary

Debug — Débogueur Voir « débogueur » sur le Wiktionnaire … Wikipédia en Français

debug — UK [diːˈbʌɡ] / US [dɪˈbʌɡ] verb [transitive] Word forms debug : present tense I/you/we/they debug he/she/it debugs present participle debugging past tense debugged past participle debugged computing to look for and remove mistakes from a computer … English dictionary

debug — transitive verb Date: 1944 1. to remove insects from 2. to eliminate errors in or malfunctions of 3. to remove a concealed microphone or wiretapping device from • debugger noun … New Collegiate Dictionary

debug — [[t]di͟ːbʌ̱g[/t]] debugs, debugging, debugged VERB When someone debugs a computer program, they look for the faults in it and correct them so that it will run properly. [V n] The production lines ground to a halt for hours while technicians tried … English dictionary

Источник