Лучшие практики для отладки

Question

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

Мой подход выглядит примерно так.

• Воспроизведите проблему. В идеале максимально уменьшить входной сигнал.

• Изучите, что идет не так, и перечислите теории, где может быть ошибка.

• Изучите одну теорию за раз, отлаживая эту конкретную область кода.

Повторите шаги по мере необходимости.

Для сложных проблем отладки я часто работаю с коллегой. Для WinDbg это особенно полезно.

Любые другие полезные советы или рекомендации по отладке?

Answer 1

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

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

Кстати, именно поэтому Линус возражал против добавления встроенной поддержки отладки ядра.

Answer 2

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

Когда вы гоняетесь за неверными данными, такими как нулевой указатель, это зависит от того, откуда они берутся: если они передаются в качестве аргумента, посмотрите на стек вызовов, чтобы выяснить, откуда они берутся. Если это часть какой-либо структуры данных или объекта (более простой случай), установите точку останова, чтобы увидеть, когда и как она будет изменена.

Условные контрольные точки могут быть очень полезны, в противном случае вы можете имитировать их, добавляя операторы if, содержащие no-ops. Если у вас есть точка останова в горячей точке, которая срабатывает слишком часто до того, как вы столкнетесь с проблемой, деактивируйте ее и поместите другую в место, которое, как вы знаете, будет сбито незадолго до того, как проблема проявится, активируйте ее в горячей точке.

Answer 3

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

Answer 4

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

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

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

Answer 5

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

Кстати, это одна из причин, по которой я обычно запускаю свои проекты веб-приложений VS через IIS, а не cassini.

Answer 6

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