Общие причины ошибок в версии выпуска, не существующей в режиме отладки

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

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

Попробуйте скомпилировать код с включенной меньшей оптимизацией.

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

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

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

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

Не вдаваясь в подробности, я предполагаю, что «не в порядке» означает, что он либо не компилируется, либо выдает какую-то ошибку во время выполнения. Проверьте, есть ли у вас код, основанный на версии компиляции, с помощью операторов #if DEBUG или методов, отмеченных атрибутом Conditional .

Конечно, например, если вы используете конструкции типа

#if DEBUG

//some code

#endif

Может, особенно если вы находитесь в сфере C.

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

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

РЕДАКТИРОВАТЬ: Я вижу, что другие упоминали это : конечно, у вас могут быть целые участки кода, которые условно исключаются, если не компилируются в режиме DEBUG. Если это так,

Да !, если у вас есть условная компиляция, могут быть ошибки синхронизации (оптимизированный код выпуска, неоптимизированный код отладки), повторное использование памяти или куча отладки.

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

Другие различия могут быть такими:

• В языке со сборкой мусора коллекционер обычно более агрессивен в режиме выпуска;
• Разметка памяти может часто бывает разным;
• Память может быть инициализированы иначе (например, может быть обнулен в режиме отладки или повторно использован агрессивно в выпуске);
• Местные жители могут быть продвинутым для регистрации значений в выпуске, что может вызвать проблемы с плавающей запятой значения.

Распространенная ошибка - использование выражения с побочным эффектом внутри ASSERT.

В .NET, даже если вы не используете условную компиляцию, например #if DEBUG , компилятор по-прежнему гораздо более либерален в отношении оптимизаций в режиме выпуска, чем в режим отладки, который также может приводить только к выпуску ошибок.

Функции библиотеки CRT ведут себя по-разному при отладке и выпуске (/ MD vs /MDd).

Например, отладочные версии часто предварительно заполняют буферы, которые вы передаете до указанной длины, чтобы проверить свое утверждение. Примеры включают strcpy_s , StringCchCopy и т. Д. Даже если строки заканчиваются раньше, ваш szDest лучше будет иметь длину n байтов!

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

• Переменные-члены или функции-члены в #ifdef _DEBUG , чтобы класс имел другой размер в отладочной сборке. Иногда #ifndef NDEBUG используется в сборке выпуска
• Точно так же существует другой #ifdef , который присутствует только в одной из двух сборок
• Отладочная версия использует отладочные версии системных библиотек, особенно функции распределения кучи и памяти
• Встроенные функции в сборку выпуска
• Порядок включения файлов заголовков. Это не должно вызывать проблем, но если у вас есть что-то вроде #pragma pack , которое не было сброшено, это может привести к неприятным проблемам.Подобные проблемы также могут возникать при использовании предварительно скомпилированных заголовков и принудительного включения
• . Кеши: у вас может быть код, такой как кеши, которые используются только в сборках выпуска, или ограничения размера кеша, которые отличаются.
• Конфигурации проекта: конфигурации отладки и выпуска могут иметь разные настройки сборки (это может произойти при использовании IDE)
• Условия гонки, проблемы с синхронизацией и разные побочные эффекты, возникающие в результате кода только для отладки

Некоторые советы, которые я накопил за годы добраться до сути ошибок отладки / выпуска:

• Попробуйте воспроизвести аномальное поведение в отладочной сборке, если можете, а еще лучше, напишите модульный тест, чтобы зафиксировать его
• Подумайте, чем они отличаются: настройки компилятора , кеши, код только для отладки. Попытайтесь временно минимизировать эти различия
• Создайте сборку выпуска с отключенной оптимизацией (чтобы у вас больше шансов получить полезные данные в отладчике) или оптимизированную сборку отладки. Минимизируя изменения между отладкой и выпуском, вы с большей вероятностью сможете определить, какая разница вызывает ошибку.