Как быстро отладить, когда что-то не так в рабочем процессе кода?

Question

Я часто сталкиваюсь со следующим сценарием отладки:

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

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

Так что мне было интересно, есть ли какие-либо инструменты для сравнения «рабочего процесса кода». Изучив команду «wt» в WinDbg, я подумал, что это возможно сделать. Например, я могу запустить команду «wt» для большинства функций с двумя различными шагами воспроизведения, а затем сравнить разницу между выходными данными. Тогда должно быть легко найти, где поток кода начинает расходиться.

Но проблема с WinDBG заключается в том, что «wt» довольно медленная (возможно, я должен использовать файл журнала вместо вывода на экран) и не очень удобна для пользователя (по сравнению с отладчиком visual studio) ... Поэтому я хочу спросить ребята, есть ли какие-либо существующие инструменты доступны? или возможно и сложно разработать «плагин» для отладчика Visual Studio для поддержки этой функции?

Спасибо

Answer 1

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

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

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

Answer 2

Я запускаю его под профилировщиком в режиме «покрытия», а затем использую diff для результатов, чтобы увидеть, какие части кода были выполнены за один прогон, а не другим.

Answer 3

Я предполагаю, что если у вас большое приложение, у вас есть хорошая регистрация или трассировка.

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

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

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

Другим полезным методом является создание диаграмм последовательности uml из файлов трассировки. Для этого вам необходимо последовательно регистрировать функции входа и выхода. Затем напишите небольшой скрипт для анализа ваших файлов трассировки и используйте sequence.jar для создания диаграмм uml в виде файлов png. Это отличный способ понять логику кода, которой вы давно не пользовались. Я обернул небольшой awk-скрипт в командный файл, я просто предоставляю файл трассировки и номер строки для запуска, затем он распутывает потоки и генерирует входной текст в sequence.jar, а затем запускает его для создания диаграммы uml.

Answer 4

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

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