что делать, если отладка работает нормально, но релиз падает

Question

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

unhandled Exception at 0x0043b134 in myapp.exe: 0xC0000005:
Access violation while reading at position 0x004bd96c

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

Что я могу сделать в такой ситуации, чтобы отследить проблему?

Answer 1

Такая проблема часто возникает из-за унифицированных переменных.Я бы начал там искать твою проблему.

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

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

Answer 2

Это могут быть две вещи:

• Одно или несколько ваших утверждений действительно работают отдельно от самой проверки
• Что-то еще

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

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

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

Answer 3

Два шага:

a) Сборка релизной сборки с отладкой символы (возможно с VS минимум)

б) Сборка релиза сборка без оптимизация

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

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

Answer 4

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

Answer 5

У меня была эта проблема, релиз / отладка нормально работали в Visual Studio, отладка работала в одиночку, но релиз зависал самостоятельно.Отладка была не совсем точной для меня, мое решение было:

Закомментируйте большую часть кода, затем build, test, uncomment, repeat, , пока не найдете раздел, вызывающий сбой.

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

Answer 6

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

Кстати, почему люди отключают утверждения в версии выпуска? В 99% случаев они не вызывают проблем с производительностью и хороши в обнаружении ошибок.

Answer 7

Отследите проблему, вставив вывод журнала здесь и там, с самого начала функции main.

Answer 8

Для меня проблема была в том, что конструктор инициализировал 2 переменные-члена в неправильном порядке.т.е. не в том порядке, в котором они были объявлены.
Я удивлен, что порядок инициализации действительно имеет значение.

Answer 9

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

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

Answer 10

Возьмите аварийный дамп с помощью Microsoft debugdiag на окнах (это бесплатно) и проанализируйте дамп с помощью того же самого.Это дает хороший стек вызовов для функции, в которой происходит сбой.Хотя, если он будет продолжать рушиться повсюду, это может быть проблемой повреждения кучи.Затем вам необходимо использовать глобальные флаги (или gflags, который является частью инструментов Microsoft для бесплатной отладки) вместе с debugdiag.Gflags даст вам место, где куча действительно будет повреждена.Надеюсь, это поможет.