Лучшие практики и инструменты для отладки различий между Отладкой и Сборками конечных версий?

Если отладка и выпуск различаются, это означает:

1. ваш код зависит от _DEBUG или аналогичных макросов (определяется при компиляции отладочной версии - нет оптимизации)
2. в вашем компиляторе есть ошибка оптимизации (я видел это несколько раз)

Вы можете легко справиться с (1) (модификация кода), но с (2) вам придется изолировать ошибку компилятора. После выделения ошибки вы делаете небольшую «переписывание кода», чтобы компилятор сгенерировал правильный двоичный код (я делал это несколько раз - самая сложная часть - изолировать ошибку).

Могу сказать, что при включении отладочной информации для релизной версии процесс отладки работает ... (хотя из-за оптимизации вы можете увидеть некоторые "странные" скачки при запуске).

Вам нужно будет иметь некоторые тесты «черного ящика» для вашего приложения - valgrind - решение в этом случае. Эти решения помогут вам найти различия между выпуском и отладкой (что очень важно).

Когда я сталкиваюсь с ошибкой, которая возникает только в выпуске, первое, что я всегда ищу, - это использование неинициализированной переменной стека в коде, над которым я работаю. В Windows среда выполнения отладки C автоматически инициализирует переменные стека известным битовым шаблоном, 0xcdcdcdcd или чем-то еще. В выпуске переменные стека будут содержать значение, которое последним было сохранено в этой ячейке памяти, что может быть неожиданным значением.

Во-вторых, я попытаюсь определить, в чем разница между отладочной и выпускной сборками. Я смотрю на настройки оптимизации компилятора, которые передаются компилятору в конфигурациях Debug и Release . Вы можете видеть, что это последняя страница свойств настроек компилятора в Visual Studio. Я начну с конфигурации выпуска и изменю аргументы командной строки, передаваемые компилятору, по одному элементу за раз, пока они не совпадут с командной строкой, которая используется для компиляции при отладке. После каждого изменения запускаю программу и воспроизводю ошибку. Это часто приводит меня к конкретным настройкам, вызывающим ошибку.

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

#pragma optimize( "", off )
void foo() {
    return 1;
}
#pragma optimize( "", on ) 

По опыту, проблемы обычно связаны с инициализацией стека, очисткой памяти в распределителе памяти или странными директивами #define , вызывающими некорректную компиляцию кода.

Еще одна «передовая практика», или, скорее, комбинация двух: автоматизированные модульные тесты и «Разделяй и властвуй».

Если у вас есть модульное приложение, и каждый модуль имеет хорошие модульные тесты, то вы сможете быстро выделить ошибочную часть.

Наиболее очевидной причиной является просто использование директив #ifdef и #ifndef, связанных с DEBUG или подобным символом, которые меняются между двумя сборками.

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

Одна конкретная проблема, которая приходит на ум - это макросы:

#ifdef _DEBUG_
  #define CHECK(CheckSymbol) { if (!(CheckSymbol)) throw CheckException(); }
#else
  #define CHECK(CheckSymbol)
#endif

также известные как soft-assert.

Ну, если вы вызываете его с функцией, которая имеет побочный эффект, или полагаетесь на него для охраны функции (исполнение контракта) и каким-то образом ловите исключение, которое он бросает в отладке, и игнорируете его... вы увидите различия в релизе :)

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

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

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

Ошибки, связанные только с выпуском, могут относиться к разным категориям, но наиболее частыми из них (помимо чего-то вроде неправильного использования утверждений) являются:

1) Неинициализированная память. Я использую этот термин для неинициализированных переменных, поскольку переменная может быть инициализирована, но по-прежнему указывает на память, которая не была инициализирована должным образом. В этом могут помочь инструменты диагностики памяти, такие как Valgrind.

2) Время (например, условия гонки).Это может быть кошмаром для отладки, но есть несколько многопоточных профилировщиков и диагностических инструментов, которые могут помочь. Я не могу предложить что-либо сразу, но в качестве примера можно привести Coverity Integrity Manager.