Сбой кода в MS Visual Studio 2005 в конфигурации RELEASE

У меня есть рабочее пространство для запуска видеокодера H.263 в цикле 31 раз, т.е. основной выполняется 31 раз для генерации 31 различных кодированных битовых потоков. Это MS Visual Studio 2005 Workspace имеет все исходные файлы C. Когда я создаю конфигурацию «DEBUG» для рабочей области, собираю и выполняю ее, она работает нормально, то есть генерирует все 31 выходной файл, как и ожидалось. Но когда я устанавливаю конфигурацию рабочей области на «RELEASE» mdoe и повторяю процесс, кодер вылетает при выполнении некоторого теста.

Теперь для отладки проверено следующее:

  1. Проанализировал код, чтобы выяснить, не пропущена ли инициализация какой-либо переменной при каждом запуске кодера
  2. Проверены различные параметры Workspace (Solution) в обоих режимах (DEBUG и RELEASE).

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

Но все же не смог прибить проблему и найти решение для этого. Есть указатели?

-Ajit.

12.08.2008 08:44:09
8 ОТВЕТОВ
РЕШЕНИЕ

Трудно сказать, в чем может быть проблема, без тщательной проверки кода. Однако...

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

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

2
12.08.2008 08:51:01

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

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

0
12.08.2008 08:48:45

Может быть проблема параллелизма двух потоков. Конфигурация DEBUG замедляет выполнение, поэтому проблема не возникает. Но только предположение.

1
12.08.2008 08:51:20

Интересная проблема. Вы уверены, что у вас нет кода условной компиляции, который не компилируется в режиме выпуска? то есть:

#if (DEBUG)
// Debug Code here
#else
// Release Code here
#endif

Это единственное, о чем я действительно могу думать .. Никогда не испытывал ничего подобного сам ..

1
12.08.2008 08:51:52

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

0
12.08.2008 10:04:14

Можете ли вы добавить символы отладки в сборку релиза и запустить ее в отладчике, чтобы увидеть, где и почему произошел сбой?

1
12.08.2008 10:12:57

Еще одна вещь для рассмотрения: в режиме отладки переменные инициализируются с 0xCCCCCCCC вместо нуля. Это может иметь некоторые неприятные побочные эффекты.

0
7.09.2012 22:59:47

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

Когда он падает? На каждом тесте? На конкретный тест? Что этот тест делает то, что другие не делают?

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

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

Вы пытались запустить код через анализатор, такой как Purify? Это медленно, но обычно стоит подождать.

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

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

1
12.08.2008 13:03:36