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

Question

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

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

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

Answer 1

Проанализируйте проблему в паре и прочитайте код пары.Сделайте заметки о проблемах, которые вы ЗНАЕТЕ, чтобы быть правдой, и попытайтесь определить, какие логические предпосылки должны выполняться для этого случая.Следуйте данным, подобным CSI.

Большинство людей инстинктивно говорят «добавьте больше журналов», и это может быть решением.Но для многих проблем это только усугубляет ситуацию, так как ведение журнала может изменить временные зависимости в достаточной степени, чтобы сделать проблему более или менее частой.Изменение частоты с 1 на 1000 до 1 на 1 000 000 не приблизит вас к истинному источнику проблемы.

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

Answer 2

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

Answer 3

На этот вопрос нет хорошего хорошего ответа, но вот что я нашел:

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

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

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

4. Перепроверьте каждое предположение. Очень часто я видел проблему, которая не была решена быстро, потому что какой-то общий вызов метода больше не исследовался, и поэтому предполагалось, что проблема неприменима. «О, это должно быть просто». (См. Пункт 1).

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

Конечно, ничто из вышеперечисленного не гарантирует ничего, но этот подход, который я нашел, последовательно дает результаты.

Answer 4

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

При такой частоте 1/100 я бы сказал, что первое, что нужно сделать, - это обработать исключения и регистрировать что угодно в любом месте, или вы могли бы потратить еще неделю на поиск этой ошибки. Также составьте приоритетный список потенциально чувствительных артикуляций и функций в вашем проекте. Например : 1 - многопоточность 2 - Дикие указатели / свободные массивы 3 - опора на устройства ввода и т.п. Это поможет вам сегментировать области, которые вы можете перебирать, как это было предложено другими авторами.

Answer 5

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

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

Другой пользователь, тот же компьютер? Один и тот же пользователь, другой компьютер? Является ли возникновение сильно периодическим? Меняет ли перезагрузка периодичность?

К вашему сведению: однажды я увидел ошибку, с которой столкнулся один человек. Я буквально имею в виду человека, а не учетную запись пользователя. Пользователь A никогда не увидит проблему в своей системе, пользователь B сядет за эту рабочую станцию, войдя в систему как пользователь A и сможет немедленно воспроизвести ошибку. У приложения не должно быть мыслимого способа узнать разницу между физическим телом в кресле. However-

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

Любая разница, которая влияет на поведение ошибки, должна быть исследована, даже если она не имеет смысла.

Answer 6

Существует большая вероятность, что ваше приложение будет MTWIDNTBMT (многопоточное, когда не нужно быть многопоточным), или, может быть, просто многопоточным (чтобы быть вежливым). Хороший способ воспроизвести спорадические ошибки в многопоточных приложениях состоит в том, чтобы разбросать следующий код (C #):

Random rnd = new Random();
System.Threading.Thread.Sleep(rnd.Next(2000));

и / или это:

for (int i = 0; i < 4000000000; i++)
{
    // tight loop
}

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

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

Answer 7

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

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

Answer 8

Какая среда разработки? Для C ++ лучшим вариантом может быть запись / воспроизведение рабочей станции VMWare, см. http://stackframe.blogspot.com/2007/04/workstation-60-and-death-of.html

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

Answer 9

Наряду с большим терпением, тихой молитвой и проклятием, вам понадобится:

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

НТН.

Answer 10

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