Что вы делаете, если не можете решить проблему?

Ответ 1

Некоторые вещи, которые помогают:

1) Сделайте перерыв, подходите к ошибке под другим углом.

2) Станьте более агрессивным с отслеживанием и протоколированием.

3) Посмотрите на это еще пару глаз.

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

5) Разбейте и сломайте вещи. (Только для облегчения стресса!)

Ответ 2

Однажды я работал в компании, которая продала клиент-серверное приложение, которое было в основном средством передачи и синхронизации файлов. И клиент, и сервер были заказными приложениями, которые мы разработали.

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

(Я забыл точную ошибку, возможно, это был 59 ERROR_UNEXP_NET_ERR или, возможно, 65 ERROR_NETWORK_ACCESS_DENIED. Насколько я помню, даже не один из документированных кодов ошибок, которые вы должны были получить от API, который мы вызывали, который обычно был блокировкой или разблокировкой в ​​разделе файла).

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

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

Инструментарий был следующим: я добавил тест на неприятный код ошибки и попросил его вызвать фрагмент кода для отправки UDP-пакета на предопределенный сетевой адрес при возникновении ошибки. Пакет UDP содержал в нем уникальную строку.

Затем я устанавливаю инструмент обнюхивания пакетов в сети. (В то время я использовал Microsoft Network Monitor). Я позиционировал его там, где он мог бы "видеть" этот пакет UDP при его отправке, а также всю связь между серверами кластеров и файловым сервером.

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

Я установил конфигурацию "стресс-теста" и отправился домой на выходные.

Когда я вернулся в понедельник, вот и мои данные. Сниффер остановился так, как ожидалось, после многих часов работы и содержал захват. Изучив захват, я обнаружил, что Серверный блок сообщений или SMB (aka CIFS aka SAMBA) связь между нашим сервером и файловым сервером на самом деле выходила на уровень TCP из-за чрезмерной загрузки на сервер. Поскольку все материалы Microsoft сильно многоуровневы, он будет просачиваться обратно через стек обмена файлами как "неожиданную" ошибку вместо того, чтобы возвращать более понятный код ошибки, который сказал "эй, вы потеряли соединение на уровне TCP".

Я немного поработал над настройками TCP для Windows и рассмотрел значения по умолчанию для версии Windows, которую мы использовали ( вероятно, NT 4 в ту эпоху) не были слишком щедрыми. Это позволяло только очень небольшое количество сбоев в соединении TCP и буме, вы были мертвы. Как только вы потеряли соединение с SMB файловым сервером, все ваши блокировки файлов были тостами, и восстановить их не удалось.

Итак, я закончил тем, что написал приложение к руководству пользователя, в котором объяснялось, как изменить настройки TCP в Windows, чтобы сделать ваш сервер кластера более терпимым к ситуациям с высокой нагрузкой. И все. Исправление ошибки было нулевым изменением кода, а всего лишь дополнительной документацией о том, как правильно настроить ОС для использования этим продуктом.

Что мы узнали?

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

Ответ 3

Я делаю несколько разных вещей:

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

• продолжать печатать заявления и утверждать утверждения, чтобы устранить вещи и позволить мне реформировать новые предположения.

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

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

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

Ответ 4

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

Ответ 5

Цитата взята из " Криптономикон":

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

Некоторые вещи, которые хорошо работают для меня:

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

Самая худшая ошибка, на мой взгляд, - это ошибка concurrency, которая исчезает при вставке журнала.

Ответ 9

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

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

Или, если проблема представляет собой "случайную" перезапись памяти, используйте замену malloc()/free(), которая перехватывает запись в "свободную" память (например, электрический забор или dmalloc).

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

Ответ 10

"Что вы делаете в этой ситуации (не спрашивая других о помощи, которая не всегда возможна)?

Когда не удается обратиться за помощью?

Есть всегда другие, к которым вы можете обратиться за помощью: ваши коллеги, ваш босс, друзья здесь, в Qaru и т.д.

Понимание того, когда обращаться за помощью не следует деморализовать!

Ответ 11

Здесь есть много хороших советов.

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

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

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

2) Если вы прибегаете к изменению кода, не зная точно, в чем проблема, тогда, если ошибка исчезнет, ​​ ВЫ ДОЛЖНЫ вернуться и понять, почему изменение исправило ошибку. В противном случае вы, вероятно, просто скрываете ошибку.

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

4) Ведение журнала.

Ответ 12

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

• Ищите лучшие инструменты для отладки. Новая перспектива проходит долгий путь. Xdebug - это то, что я начал использовать на PHP только из-за ошибки производительности, с которой я не продвигался вперед.

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

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

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

Я заметил несколько общностей в этих ошибках, которые я застрял в течение нескольких недель:

• Просить сторонних сторонников помочь редко помогает, и, как правило, не стоит ждать, пока кто-то еще придет, сохранит этот день.

• Почти всегда ошибка возникает в какой-то третьей технологии закрытого источника, особенно при использовании неясных деталей. У IE были неприятные ошибки при попытке использовать клиентские сертификаты. Flash не справлялся со случайными генерируемыми инструкциями по рисованию (некоторые из них были бессмысленными). Outlook не нравится, когда вы пытаетесь динамически изменять формат формы из кода. В эти дни я научился уважать "зоны комфорта" проприетарной технологии.

Ответ 13

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

Ответ 14

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

Надеюсь, что это поможет.

Ответ 15

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

В python, если я использую редактор, который не принадлежит мне, или, может быть, это код другого пользователя, я использую retab! в vim или вставляю что-то вроде пасты для проверки отступов (если у меня нет vim).

Если это не прерыватель crasher/deal, то я двигаюсь дальше и возвращаюсь со свежими парами глаз.

О, и у вас никогда не будет слишком много регистрации.

Ответ 16

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

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

Ответ 17

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

RWendi

Ответ 18

Во-первых, это воспроизводимо? Это ОГРОМНЫЙ плюс, если он есть. Я хочу, чтобы ошибки всегда были/никогда не случались... его прерывистые, которые являются трудными.

И это будет зависеть от проблемы, но в моем магазине мы обычно будем тегировать такую ​​проблему, считая, что 2 головки (или 3 или 4) лучше, чем 1.

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

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

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

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

Что я делаю.

Ответ 19

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

Ответ 20

Я рассмотрел просьбу о помощи на этом веб-сайте под названием /fooobar.com/..., который я недавно посещал...

Ответ 21

Серьезно? Я делаю что-то в этом порядке.

• В постели
• Спросите коллегу
• Перепишите так, чтобы область не была затронута.
• Запросить SO
• Поднимите билет поддержки со своим сторонним разработчиком библиотеки.

Ответ 22

Это то, что я сделал сегодня...

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

Поэтому я должен:

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

Инструмент до и после ошибки для печати изменений состояния.

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

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

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

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

Нет ответов, эта ошибка моя, чтобы решить...

Это взаимодействие HW SW - это цикл, который выполняет некоторую настройку, затем вводит цикл опроса, который читает, когда транзакция завершена. Должно произойти много транзакций. Какая транзакция не удалась? Это первый (указывает, что я могу отлаживать транзакцию, а не некоторый шум в HW). Это всегда транзакция Nth? Что делает Nth отличным от первого или (N-1) -го. SW однопоточный и построен, чтобы быть предсказуемым. Нет препретов, без прерываний.

Этот SW работал раньше, что нового? Все HW новы. В этом случае весь кремний является новым как его ASIC. Даже встроенный процессор является новым и настраивается, поэтому ISA является новым.

Итак, я все подозреваю, и я слепой. Мне придется подкрасться к этой плотве.

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

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

Посмотрел на все проверки, увидел, что подрядчик изменил некоторые важные параметры настройки без объяснения причин. Эти (сторонние) люди по-прежнему оцениваются. Это не поможет.

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

Ограничено количество транзакций, чтобы увидеть, где он не работает, где-то до 1000.

Настройте HW для работы медленнее, все еще зависает.

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

Ответ 23

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

Ответ 24

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

используя удаленную отладку на машине, где она воспроизводится.

с использованием инструментов профилирования.

ввести больше регистрации в приложение.

Ответ 25

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

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

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

Ответ 26

Уход на некоторое время, а затем возвращение к проблеме - это один общий подход, который я делаю и слышал.

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

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

Вы отказались от категории "встречается под другой O/S", так что веб-страница, которая отлично работает в IE и Firefox на ПК, может выглядеть как дерьмо в Safari на Mac. У меня грязные руки, пытаясь исправить проблему с CSS, используя мою машину в качестве сервера и Mac, которая находится над строкой или двумя в ячейках пола, чтобы увидеть эту проблему, или она настолько низкая, что она получает прокатилась под ковриком? В качестве альтернативы, если ошибка была в Linux и рядом с ней нет каких-либо Linux-машин, что мне делать?

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

Ответ 27

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

Я иногда пытаюсь переопределить то, что другие называют ошибкой, поскольку это действительно функция, но это редко работает!

Ответ 28

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

• реорганизован некоторый код, который, как я думал, вызывал его
• добавлены дополнительные отладочные отпечатки, где он, кажется, разбился.
• перенаправленный stdout, так что в следующий раз, когда я его увижу, я могу < kill -3 "выполнить
• предоставляется поддержка некоторых новых инструментов для выгрузки текущего состояния блокировок базы данных и т.п.
• добавлена ​​диагностика, чтобы сделать ее более очевидной, когда это произойдет.

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

Ответ 29

Если это не критично, не исправляйте это, вы просто потратите слишком много времени!

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

Ответ 30

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