Какой совет для отладки действительно трудно отследить ошибки?

Question

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

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

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

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

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

Очевидно, что нет простых ответов, так как я не спрашиваю о конкретной ошибке, но каковы общие принципы и тактики для решения таких проблем?

Answer 1

Ну, я думаю, что отчасти это должно быть соображением дизайна, что некоторые могут назвать «корпоративной заботой» - включение наполовину достойного ведения журнала / трассировки и инструментария поможет в отладке (особенно с настраиваемым многословием!) Даже добавление в приложение пары пользовательских счетчиков производительности иногда может помочь при отладке условий гонки ... если вам нужно пойти на крайние меры.

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

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

Answer 2

Систематическое ведение журнала может помочь:

• Журнал на интерфейсах, чтобы вы могли сузить его до одного компонента.

• Регистрировать изменения внутреннего состояния, когда их трудно определить из того, что происходит на интерфейсах.

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

Answer 3

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

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

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

Если подумать, многие шаблоны описаны в разделе «Рефакторинг».

Answer 4

С большинством ошибок вы обнаруживаете их после события и исправляете их, пытаясь воссоздать обстоятельства. Простой баг = простой отдых.

Ключом к вашей проблеме является возможность воссоздать обстоятельства. В сложной среде, подобной этой, я думаю, что единственный способ сделать это - это взять каждую точку интерфейса, которая может дать сбой, и реализовать ведение журнала для этого интерфейса, то есть дамп в файл и / или БД. Конечно, вы не хотели бы, чтобы это было включено постоянно, но вы должны закодировать его с самого начала. Затем настройте тестовую среду, которую затем можно будет использовать на основе данных журнала. Таким образом, вы можете запускать и перезапускать обстоятельства, пока не создадите заново ошибку, и тогда вы на 80% сможете ее решить.

Answer 5

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

Очевидно, это может показаться немного спорным, но он говорит, что это очень помогает в получении отзывов о том, как система работает в «реальном мире».