Ответ 1

Они известны как Heisenbugs.

Язык

У разных языков программирования будет свой собственный вкус ошибок.

С

Добавление отладочных инструкций может сделать проблему невозможной для дублирования, потому что сам оператор отладки сдвигает указатели (достаточно далеко, чтобы избежать SEGFAULT). Проблемы с указателями - это кошмар для отслеживания и репликации, но есть отладчики (такие как GDB и DDD), которые могут помочь.

Java

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

JavaScript

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

Окружающая среда

В зависимости от сложности среды, в которой работает приложение (с ошибкой), единственным средством защиты может быть упрощение среды. Выполняется ли приложение:

• на сервере?
• на рабочем столе?
• в веб-браузере?

В какой среде приложение создает проблему?

• развитие?
• тест?
• производства?

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

Сеть

Поскольку сетевое взаимодействие имеет важное значение для столь многих приложений:

• Обеспечьте стабильные сетевые подключения, включая беспроводные сигналы.
• Сопровождается ли программное обеспечение после сбоев сети?
• Все ли соединения закрыты должным образом, чтобы освободить дескрипторы файлов?
• Люди, использующие машину, не должны быть?
• Могут ли устройства-изгои взаимодействовать со станционной сетью?
• Есть ли поблизости фабрики или радиобазы, которые могут вызывать помехи?
• Имеются ли размеры и частота пакетов в пределах номинального диапазона?
• Все ли сетевые устройства подходят для интенсивного использования полосы пропускания?

Согласованность

Устранить как можно больше неизвестных:

• Изолировать архитектурные компоненты.
• Удалить несущественные или, возможно, проблематичные (конфликтующие) элементы.
• Деактивировать различные прикладные модули.

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

Вход

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

Оборудование

Если программное обеспечение выглядит нормально, рассмотрите аппаратные ошибки:

• Являются ли физические сетевые соединения прочными?
• Есть ли свободные кабели?
• Правильно ли установлены чипы?
• У всех кабелей есть чистые соединения?
• Является ли рабочая среда чистой и свободной от пыли?
• Были ли повреждены какие-либо скрытые устройства или кабели грызунами или насекомые?
• Существуют ли на дисках плохие блоки?
• Работают ли вентиляторы процессора?
• Может ли материнская плата использовать все компоненты? (Процессор, сетевая карта, видеокарта, диски и т.д.).
• Может ли быть виновником электромагнитных помех?

И в основном для встроенных:

• Недостаточное количество обходных каналов?
• Загрязнение платы?
• Плохие соединения с пайкой/плохое перепланирование
• CPU не reset, когда напряжение питания не соответствует допустимому пределу?
• Плохо сбрасывается, потому что рельсы питания работают от портов ввода/вывода и не полностью разряжаются?
• Защелка вверх?
• Плавающие входные контакты?
• Недостаточные (иногда отрицательные) шумовые поля на логических уровнях?
• Недостаточные (иногда отрицательные) временные поля?
• Оловянные бакенбарды?
• Повреждение ESD?
• ESD расстраивает?
• Исправлены ошибки chip?
• Неправильное использование интерфейса (например, I2C вне сети или при наличии мощных сигналов)?
• Условия гонки?
• Поддельные компоненты?

Сеть против локальной

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

Firmware

Между аппаратным и программным обеспечением находится прошивка.

• Обновлен ли BIOS компьютера?
• Работает ли батарея BIOS?
• Синхронизированы ли часы BIOS и системные часы?

Время и статистика

Тревожные проблемы трудно отслеживать:

• Когда возникает проблема?
• Как часто?
• Какие еще системы работают в то время?
• Является ли приложение зависящим от времени (например, будет високосный или скачок секунд причиной проблем)?

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

Управление изменениями

Иногда возникают проблемы после обновления системы.

• Когда первая проблема началась?
• Что изменилось в среде (аппаратное и программное обеспечение)?
• Что происходит после возврата к предыдущей версии?
• Какие существуют различия между проблемной версией и хорошей версией?

Управление библиотекой

Различные операционные системы имеют разные способы распространения конфликтующих библиотек:

• Windows имеет DLL Hell.
• Unix может иметь многочисленные сломанные символические ссылки.
• Файлы библиотеки Java могут быть одинаково кошмарными для решения.

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

Java

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

Используйте инструмент управления библиотекой, например Maven или Ivy.

Отладка

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

Спящий

Стоит повторить то, что говорили другие: спать на нем. Проведите время в стороне от проблемы, выполните другие задачи (например, документацию). Физически удаляйтесь от компьютеров и выполняйте некоторые упражнения.

Обзор кода

Пройдите через код, по очереди, и опишите, что каждая строка делает для себя, сотрудника или резиновая утка. Это может привести к пониманию того, как воспроизвести ошибку.

Космическое излучение

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

Инструменты

Редко, но это происходит, особенно для нишевых инструментов (например, компилятор C-микроконтроллера C, страдающий переполнением таблицы символов).

Ответ 2

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

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

Сообщает ли ваше приложение номер версии, номер сборки и т.д.? Вам нужно это, чтобы точно определить, какую версию вы отлаживаете (или нет!).

Если вы можете настроить приложение (например, с помощью JMX, если вы находитесь в мире Java), тогда примените эту область. Хранить статистику, например. запросы + параметры, время и т.д. Используйте буферы для хранения последних "n" запросов/ответов/версий объектов/независимо, и выгружайте их, когда пользователь сообщает о проблеме.

Ответ 3

Если вы не можете его реплицировать, вы можете исправить это, но не можете знать, что вы его исправили.

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

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

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

Ответ 4

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

Это может помочь добавить кучу проверки ошибок и утверждений, чтобы подтвердить или опровергнуть ваши убеждения/предположения. Что-то может потерпеть неудачу, чего вы никогда не ожидали.

Ответ 5

Сделайте случайные изменения, пока что-то не сработает: -)

Ответ 6

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

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

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

Ответ 7

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

Ответ 8

Существует два типа ошибок, которые нельзя реплицировать. Вид, который вы обнаружили, и вид, который кто-то открыл.

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

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

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

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

Ответ 9

Предполагая, что вы уже добавили все записи, которые, по вашему мнению, помогут, и это не... две вещи spring:

• Работайте назад от сообщенного симптома. Подумайте о себе.. "Я хотел создать симптом, о котором сообщалось, какой код мне нужно будет выполнять, и как я получу его, и как я получу это?" D приводит к C приводит к B. приводит к A. Принимайте, что если ошибка не воспроизводится, то нормальные методы не помогут. Мне приходилось много часов смотреть на код с такими процессами мышления, чтобы найти некоторые ошибки. Обычно это оказывается чем-то действительно глупым.

• Помните Боб первый закон отладки: если вы не можете найти что-то, это потому, что вы ищете не в том месте: -)

Ответ 10

Думать. Жесткий. Заблокируйте себя, не допускайте никаких перерывов.

У меня когда-то была ошибка, где доказательство было шестым дампом поврежденной базы данных. Цепочки указателей систематически прикручивались. Все пользовательские программы и наше программное обеспечение для баз данных безупречно работали при тестировании. Я смотрел на него в течение недели (это был важный клиент), и после устранения десятков возможных идей я понял, что данные были распределены по двум физическим файлам, а коррупция произошла там, где цепи пересекали границы файлов. Я понял, что если операция резервного копирования/восстановления завершилась неудачно в критической точке, эти два файла могут оказаться "не синхронизированными", восстановленными в разные моменты времени. Если вы затем запустили одну из клиентских программ по уже поврежденным данным, она создала бы точно узловатые цепи указателей, которые я видел. Затем я продемонстрировал последовательность событий, которые точно воспроизвели коррупцию.

Ответ 11

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

Ответ 12

Начните с изучения того, какие инструменты у вас есть. Например, сбои на платформе Windows переходят в WinQual, поэтому, если это ваш случай, теперь у вас есть информация о дампе аварий. Можете ли вы статические инструменты анализа обнаружить потенциальные ошибки, инструменты анализа времени выполнения, инструменты профилирования?

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

Наконец, как сказал Дэвид, смотрите на код.

Ответ 13

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

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

Ответ 14

Существуют такие инструменты, как gotomeeting.com, которые вы можете использовать для совместного использования экрана с вашим пользователем и наблюдения за поведением. Могло быть много потенциальных проблем, таких как количество программных средств, установленных на их машинах, а некоторые утилиты инструментов конфликтуют с вашей программой. Я считаю, что gotomeeting, это не единственное решение, но могут быть проблемы с тайм-аутом, медленная интернет-проблема.

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

Ответ 15

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

Поэтому, боюсь, я, вероятно, закрою ошибку как WORKSFORME (Bugzilla), а затем займусь исправлением некоторых более ощутимых ошибок. Или делать то, что решает руководитель проекта.

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