Самые твердые типы ошибок для отслеживания? [закрытый]

Трудность отслеживания:

• ошибки диапазона
• ошибки граничного условия

Неинициализированные переменные. (Или современные языки покончили с этим?)

Зависимые проблемы машины.

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

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

Gak.

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

ПУТЬ назад в дни, утечки памяти. К счастью существует много инструментов для нахождения их в эти дни.

Косметическое веб-моделирование вовлечения ошибок в различном браузере, который конфигурации O/S, например, страницу выглядит хорошо в Windows и Mac в Firefox и IE, но на Mac в Safari что-то испорчено. Они иногда являются раздражающими, потому что они требуют такого внимания к деталям, и внесение изменения для фиксации Safari может повредить что-то в Firefox или IE, таким образом, нужно действовать осторожно и понять, что моделирование может быть рядом взломов для фиксации страницы после страницы. Я сказал бы, что это - мои самые противные, которые иногда просто не становятся фиксированными, поскольку они не просматриваются как важные.

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

Проблемы памяти, особенно в более старых системах. У нас есть некоторое 16-разрядное программное обеспечение C прежней версии, которое должно остаться 16-разрядным в настоящее время. 64K блоки памяти являются королевской болью для работы с, и мы постоянно добавляем помехи или кодируем логику, которая продвигает нас мимо 64K пределов группы.

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

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

Для встроенных систем:

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

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

Переполнение буфера (в собственном коде)

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

Повреждение памяти при загрузке из-за неисправного оборудования.

Самый твердый когда-либо был на самом деле ошибкой, с которой я помогал другу. Он писал C в Visual Studio MS 2005 и забыл включать time.h. Он далее назвал время без обязательного аргумента, обычно ПУСТОЙ УКАЗАТЕЛЬ. Это неявно заявленное время как: международное время (); Это повредило стек, и абсолютно непредсказуемым способом. Это был большой объем кода, и мы не думали для взгляда в то время () призыв приблизительно к время .

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

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

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

Мы разрабатывали базу данных для содержания слов и определений на другом языке. Оказывается, что этот язык был только недавно добавлен к стандарту Unicode, и это не превращало его в SQL Server 2005 (хотя это было добавлено приблизительно в 2005). Это имело очень расстраивающий эффект, когда он пришел к сопоставлению.

Слова и определения вошли очень хорошо, я видел все в Studio управления. Но каждый раз, когда мы пытались найти определение для пообещанного, наши запросы ничего не возвратили. После твердых 8 часы отладки я был при размышлении, что я потерял способность записать простой Запрос Select.

таким образом, пока я не заметил, английские буквы соответствовали другим английским буквам любой сумме внешних добавленных букв. Например, EnglishWord соответствовал бы E! $ish$ n@gl## & Word. (С! # % $ ^& * представление внешних букв).

, Когда сопоставление не знает об определенном символе, оно не может отсортировать их. Если это не может отсортировать их, это не может сказать ли два строковых соответствия или не (удивление для меня). Так срыв и целый день коту под хвост для глупой установки сопоставления.

Вероятно, не самое твердое, но они чрезвычайно распространены и не тривиальны:

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

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

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

, Который был СУКОЙ для отслеживания.

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

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

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

Самые трудные ошибки, чтобы разыскать и зафиксировать являются теми, которые комбинируют все трудные случаи:

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

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

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

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

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

В конце отладчик, доказанный рядом с бесполезным, потому что катастрофические отказы никогда не происходили в дереве вызова для незаконной функции. Хорошо упорядоченный поток fprintf (stderr...) вызовы в коде и дампе вывода в файл были тем, что в конечном счете позволило нам определять, какова проблема была.

У моего друга была эта ошибка. Он случайно поместил аргумент функции в программу C в квадратных скобках вместо круглой скобки как это: foo[5] вместо foo(5). Компилятор был совершенно счастлив, потому что имя функции является указателем, и нет ничего недопустимого об индексации от указателя.

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

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

Вот пример ошибки параллелизма в Guice 1.0, которого я определил местоположение только несколько дней назад. Можно протестировать навыки нахождения ошибки путем попытки узнать то, что является ошибкой, вызывающей то исключение. Ошибка не слишком трудна для нахождения - я нашел ее причину приблизительно в 15-30 минут (ответ здесь ).

java.lang.NullPointerException 
    at com.google.inject.InjectorImpl.injectMembers(InjectorImpl.java:673) 
    at com.google.inject.InjectorImpl$8.call(InjectorImpl.java:682) 
    at com.google.inject.InjectorImpl$8.call(InjectorImpl.java:681) 
    at com.google.inject.InjectorImpl.callInContext(InjectorImpl.java:747) 
    at com.google.inject.InjectorImpl.injectMembers(InjectorImpl.java:680) 
    at ...

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

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

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

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

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

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