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

Question

Каковы типичные причины ошибок и ненормального поведения программы, которые проявляются только в режиме компиляции релиза, но не возникают в режиме отладки?

Answer 1

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

Кроме этого, это невозможно. Существуют различия в том, как код отладки и код выпуска компилируются, и различия в том, как выполняется код, если он выполняется в отладчике или нет, но если любое из этих различий вызывает что-то кроме различия в производительности, проблема была там все время. 1003 *

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

Я только что испытал это, когда вызывал функцию сборки, которая не восстановила предыдущие значения регистров.

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

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

Answer 6

Я помню некоторое время назад, когда мы собирали dll и pdb на c / c ++.

Я помню это:

• Добавление данных журнала иногда приводило к тому, что ошибка перемещалась или исчезала, или появлялась совершенно другая ошибка (так что на самом деле это не выход).
• Многие из этих ошибок произошли из-за распределения символов в strcpy и strcat и массивов char [] и т. Д ...
• Мы отсеяли часть, запустив проверку границ и просто исправив вопросы выделения / освобождения памяти.
• Много раз мы систематически просматривали код и исправляли распределение символов (как и во всех файлах).
• Определенно, это связано с распределением памяти и управлением, а также с ограничениями и различиями между режимом отладки и режимом выпуска.

А потом надеялся на лучшее.

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

Answer 7

Другими причинами могут быть вызовы БД. Вы сохраняете и обновляете одну и ту же запись несколько раз в одной теме, иногда для обновления. Возможно, обновление завершилось неудачно или не сработало так, как ожидалось, поскольку предыдущая команда create все еще обрабатывала, а для обновления вызов db не смог найти ни одной записи. это не происходит при отладке, так как отладчик проверяет выполнение всех отложенных задач перед приземлением.

Answer 8

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