Как вы воспроизводите ошибки, которые возникают спорадически?

Question

В нашем приложении есть ошибка, которая возникает не каждый раз, и поэтому мы не знаем ее "логику". Сегодня я даже не воспроизводил его 100 раз.

Отказ от ответственности: эта ошибка существует, и я видел ее. Это не pebkac или что-то подобное.

Каковы общие подсказки для воспроизведения такого рода ошибки?

Answer 1

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

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

Answer 2

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

Сосредоточьтесь на утилизации ресурсов; я обнаружил, что многие хитрые спорадические ошибки были связаны с тем, что они закрывали \): *. 1003 *

Answer 3

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

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

И это не гарантирует, что мы все вместе сможем его найти ...

Answer 4

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

Answer 5

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

(0) Проверьте оперативную память системы, используя что-то вроде Memtest86!

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

Он не терпит неудачу в 100% случаев, поэтому вы должны делать это чаще.

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

Посмотрите, все ли не получится. Это терпит неудачу чаще?

Ведите надлежащие записи испытаний и меняйте только одну переменную за раз!

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

У меня нет потоков и только один процесс, и я не общаюсь с оборудованием

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

Для многопоточных задач:

Попробуйте запустить его на другом количестве процессоров. Если он работает на 1, попробуйте на 4! Попробуйте заставить 4-компьютерную систему на 1. В основном это будет гарантировать, что все происходит по одному.

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

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

И наоборот, попробуйте работать медленнее на временных срезах.

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

Если ничего не помогает, поместите оборудование в морозильник и запустите его там. Время все будет смещено.

Answer 6

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

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

1) Проанализируйте исходный код и определите, каковы источники недетерминированности в приложении, то есть, какие аспекты могут привести ваше приложение к различным путям выполнения (например, ввод данных пользователем, сигналы ОС)

2) Зарегистрируйте их при следующем запуске приложения

3) При повторном сбое приложения у вас есть шаги для воспроизведения ошибки в вашем журнале.

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

http://www.gsd.inesc -id.pt / ~ nmachado / Программное обеспечение / Symbiosis_Tutorial.html

С наилучшими пожеланиями

Answer 7

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

http://code.google.com/p/elmah/

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

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

Они в основном выходят ночью ... в основном

Answer 8

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

Если что-то происходит с несколькими пользователями, но вы не можете воспроизвести это, и они могут, посидите с ними и посмотрите. Если это не очевидно, поменяйте сидения - вы «едете», и они говорят вам, что делать. Таким образом вы обнаружите тонкие проблемы с юзабилити. двойной щелчок на кнопке одним нажатием, например, запуск повторного входа в событие OnClick. Что-то в этом роде. Если пользователи являются удаленными, используйте WebEx, Wink и т. Д., Чтобы записать их сбой, чтобы вы могли проанализировать воспроизведение.