Сбой кода в MS Visual Studio 2005 в конфигурации RELEASE - PullRequest
2 голосов
/ 12 августа 2008

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

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

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

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

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

-Ajit.

Ответы [ 8 ]

2 голосов
/ 12 августа 2008

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

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

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

1 голос
/ 12 августа 2008

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

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

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

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

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

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

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

1 голос
/ 12 августа 2008

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

1 голос
/ 12 августа 2008

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

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

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

1 голос
/ 12 августа 2008

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

0 голосов
/ 12 августа 2008

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

0 голосов
/ 12 августа 2008

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

0 голосов
/ 12 августа 2008

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

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

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