Отладка - Debugging

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

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

Происхождение термина

Запись компьютерного журнала от Mark II, с наклеенной на страницу ночной бабочкой.

Термины «ошибка» и «отладка» обычно приписываются Адмирал Грейс Хоппер в 1940-е гг.[1] Пока она работала над Марк II компьютер в Гарвардском университете, ее сотрудники обнаружили мотылек, застрявший в реле и тем самым препятствующий работе, после чего она заметила, что они «отлаживают» систему. Однако термин «ошибка» в смысле «техническая ошибка» восходит как минимум к 1878 году и Томас Эдисон (увидеть программная ошибка для полноценного обсуждения). Точно так же термин «отладка», кажется, использовался как термин в аэронавтике до того, как войти в мир компьютеров. В самом деле, в интервью Грейс Хоппер отметила, что она не придумывала этот термин.[нужна цитата ] Мотылек подходил к уже существующей терминологии, поэтому его спасли. Письмо от Дж. Роберт Оппенгеймер (директор проекта создания атомной бомбы времен Второй мировой войны «Манхэттен» в Лос-Аламосе, Нью-Мексико) использовал этот термин в письме доктору Эрнест Лоуренс в Калифорнийском университете в Беркли от 27 октября 1944 г.,[2] относительно найма дополнительного технического персонала.

В Оксфордский словарь английского языка В статье «отладка» цитируется термин «отладка», использованный в отношении испытаний авиационных двигателей в статье 1945 года в Журнале Королевского авиационного общества. Статья в «Военно-воздушных силах» (июнь 1945 г., стр. 50) также относится к отладке, на этот раз авиационных камер. Хоппера ошибка была найдена 9 сентября 1947 года. Программисты не использовали этот термин до начала 1950-х годов. Основополагающая статья Гилла[3] в 1951 году - самое раннее подробное обсуждение ошибок программирования, но в нем не используются термины «ошибка» или «отладка». ACM В электронной библиотеке термин «отладка» впервые был использован в трех статьях, опубликованных на Национальных собраниях ACM 1952 года.[4][5][6] Двое из трех используют этот термин в кавычках. К 1963 году «отладка» был достаточно распространенным термином, который можно было упомянуть мимоходом без объяснения на странице 1 CTSS руководство по эксплуатации.[7]

Пегги А. Кидвелл статья Преследование неуловимой компьютерной ошибки[8] обсуждает этимологию понятий «ошибка» и «отладка» более подробно.

Объем

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

инструменты

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

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

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

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

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

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

Процесс отладки

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

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

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

Методы

  • Интерактивная отладка
  • Отладка печати (или трассировка) - это процесс наблюдения (в реальном времени или в записи) операторов трассировки или операторов печати, которые указывают ход выполнения процесса. Иногда это называют printf отладка, за счет использования printf функция в C. Этот вид отладки был включен командой TRON в исходных версиях ориентированных на новичков БАЗОВЫЙ язык программирования. TRON расшифровывался как «Trace On». TRON заставлял печатать номера строк каждой BASIC-командной строки во время работы программы.
  • Удаленная отладка это процесс отладки программы, работающей в системе, отличной от отладчика. Чтобы начать удаленную отладку, отладчик подключается к удаленной системе по каналу связи, например по локальной сети. Затем отладчик может контролировать выполнение программы в удаленной системе и получать информацию о ее состоянии.
  • Посмертная отладка отладка программы после того, как она уже разбился. Связанные методы часто включают в себя различные методы трассировки, такие как изучение файлов журналов, вывод стек вызовов при аварии,[9] и анализ дамп памяти (или дамп ядра ) потерпевшего крах процесса. Дамп процесса может быть получен системой автоматически (например, когда процесс завершился из-за необработанного исключения), или введенной программистом инструкцией, или вручную интерактивным пользователем.
  • Алгоритм «Волчий забор»: Эдвард Гаусс описал этот простой, но очень полезный и теперь известный алгоритм в статье 1982 г. Коммуникации ACM следующим образом: «На Аляске есть один волк; как вы его нашли? Сначала постройте забор в центре штата, подождите, пока волк завоет, определите, с какой стороны забора он находится. Повторите процесс только с этой стороны. , пока не дойдете до точки, где можно увидеть волка ".[10] Это реализовано, например, в Git система контроля версий как команда git bisect, который использует описанный выше алгоритм для определения совершить внесла конкретную ошибку.
  • Запись и воспроизведение отладки это метод создания записи выполнения программы (например, с использованием бесплатного Mozilla rr средство отладки; включение обратимая отладка / execute), которые можно воспроизводить и отлаживать в интерактивном режиме. Полезно для удаленной отладки и устранения периодических, недетерминированных и других трудно воспроизводимых дефектов.
  • Дельта-отладка - методика автоматизации упрощения тест-кейсов.[11]:стр.123
  • Saff Squeeze - метод локализации сбоя в тесте с использованием постепенного встраивания частей неудавшегося теста.[12]
  • Отслеживание причинно-следственной связи: Существуют методы отслеживания причинно-следственных цепочек в вычислениях.[13] Эти методы могут быть адаптированы для конкретных ошибок, таких как разыменование нулевого указателя.[14][15]

Отладка встроенных систем

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

Несмотря на упомянутую выше проблему неоднородности, некоторые отладчики были разработаны как в коммерческих целях, так и в качестве исследовательских прототипов. Примеры коммерческих решений взяты из Программное обеспечение Green Hills,[16] Lauterbach GmbH[17] и MPLAB-ICD от Microchip (для внутрисхемного отладчика). Два примера инструментов исследовательских прототипов: Aveksha.[18] и Flocklab.[19] Все они используют функциональность, доступную на недорогих встроенных процессорах, встроенный модуль отладки (OCDM), сигналы которого отображаются через стандартный JTAG интерфейс. Они оцениваются на основе того, сколько изменений требуется в приложении, и скорости событий, за которыми они могут успевать.

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

Анти-отладка

Анти-отладка - это «реализация одного или нескольких методов в компьютерном коде, которые препятствуют попыткам обратный инжиниринг или отладка целевого процесса ».[20] Его активно используют признанные издатели в защита от копирования схемы, но также используется вредоносное ПО затруднить его обнаружение и устранение.[21] Методы, используемые для защиты от отладки, включают:

  • На основе API: проверьте наличие отладчика с помощью системной информации
  • На основе исключений: проверьте, не мешают ли исключения
  • Блоки процессов и потоков: проверьте, управлялись ли блоки процессов и потоков.
  • Измененный код: проверьте наличие изменений кода, сделанных отладчиком, обрабатывающим программные точки останова.
  • На основе оборудования и регистров: проверка аппаратных точек останова и регистров ЦП
  • Время и задержка: проверьте время, затраченное на выполнение инструкций
  • Обнаружение и наказание отладчика[21]

Ранний пример анти-отладки существовал в ранних версиях Microsoft Word который, если был обнаружен отладчик, выдавал сообщение, которое гласило: «Древо зла приносит горькие плоды. Теперь мусор программный диск.», после чего привод гибких дисков издавал тревожные звуки с намерением отпугнуть пользователя. от попытки снова.[22][23]

Смотрите также

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

  1. ^ InfoWorld 5 октября 1981 г.
  2. ^ https://bancroft.berkeley.edu/Exhibits/physics/images/bigscience25.jpg
  3. ^ С. Гилл, Диагностика ошибок в программах на EDSAC, Труды Лондонского королевского общества. Серия A, Математические и физические науки, Vol. 206, No. 1087 (22 мая 1951 г.), стр. 538-554
  4. ^ Роберт В. Д. Кэмпбелл, Эволюция автоматических вычислений, Протоколы национального собрания ACM 1952 г. (Питтсбург), стр. 29-32, 1952 г.
  5. ^ Алекс Орден, Решение систем линейных неравенств на цифровой вычислительной машине., Протоколы национального собрания ACM 1952 г. (Питтсбург), стр. 91-95, 1952.
  6. ^ Ховард Б. Демут, Джон Б. Джексон, Эдмунд Кляйн, Н. Метрополис, Уолтер Орведаль, Джеймс Х. Ричардсон, МАНЬЯК doi = 10.1145 / 800259.808982, Протоколы национального собрания ACM 1952 г. (Торонто), стр. 13–16
  7. ^ Совместимая система разделения времени, M.I.T. Пресса, 1963 г.
  8. ^ Пегги Олдрич Кидвелл, Преследование неуловимой компьютерной ошибки, IEEE Annals of the History of Computing, 1998.
  9. ^ «Посмертная отладка».
  10. ^ Э. Дж. Гаусс (1982). «Практические методы: алгоритм« Wolf Fence »для отладки». Коммуникации ACM. Дои:10.1145/358690.358695. S2CID  672811.
  11. ^ Целлер, Андреас (2005). Почему программы терпят неудачу: руководство по систематической отладке. Морган Кауфманн. ISBN  1-55860-866-4.
  12. ^ "Кент Бек, Hit 'em High, Hit' em Low: регрессионное тестирование и Saff Squeeze". Архивировано из оригинал 11 марта 2012 г.
  13. ^ Зеллер, Андреас (2002-11-01). «Выделение причинно-следственных цепочек из компьютерных программ». Примечания по разработке программного обеспечения ACM SIGSOFT. 27 (6): 1–10. Дои:10.1145/605466.605468. ISSN  0163-5948. S2CID  12098165.
  14. ^ Бонд, Майкл Д .; Nethercote, Николас; Кент, Стивен В .; Guyer, Samuel Z .; МакКинли, Кэтрин С. (2007). «Отслеживание плохих яблок». Материалы 22-й ежегодной конференции ACM SIGPLAN по системам и приложениям объектно-ориентированного программирования - OOPSLA '07. п. 405. Дои:10.1145/1297027.1297057. ISBN  9781595937865. S2CID  2832749.
  15. ^ Корню, Бенуа; Барр, Эрл Т .; Сейнтюрье, Лайонел; Монперрус, Мартин (2016). "Casper: автоматическое отслеживание нулевых разыменований на начало со следами причинности". Журнал систем и программного обеспечения. 122: 52–62. Дои:10.1016 / j.jss.2016.08.062. ISSN  0164-1212.
  16. ^ «Аппаратный отладчик SuperTrace Probe». www.ghs.com. Получено 2017-11-25.
  17. ^ «Отладчик и инструменты трассировки в реальном времени». www.lauterbach.com. Получено 2020-06-05.
  18. ^ Танкрети, Мэтью; Хоссейн, Мохаммад Саджад; Багчи, Саурабх; Рагхунатан, Виджай (2011). «Авекша: программно-аппаратный подход к неразрушающему отслеживанию и профилированию встроенных беспроводных систем». Материалы 9-й конференции ACM по встроенным сетевым сенсорным системам. SenSys '11. Нью-Йорк, Нью-Йорк, США: ACM: 288–301. Дои:10.1145/2070942.2070972. ISBN  9781450307185. S2CID  14769602.
  19. ^ Лим, Роман; Феррари, Федерико; Циммерлинг, Марко; Вальзер, Кристоф; Зоммер, Филипп; Бейтель, янв (2013). «FlockLab: испытательный стенд для распределенного, синхронизированного отслеживания и профилирования встроенных беспроводных систем». Материалы 12-й Международной конференции по обработке информации в сенсорных сетях. IPSN '13. Нью-Йорк, Нью-Йорк, США: ACM: 153–166. Дои:10.1145/2461381.2461402. ISBN  9781450319591. S2CID  447045.
  20. ^ Шилдс, Тайлер (2008-12-02). «Серия Anti-Debugging - Часть I». Veracode. Получено 2009-03-17.
  21. ^ а б «Защита программного обеспечения с помощью анти-отладки Майкл Н. Ганьон, Стивен Тейлор, Ануп Гош» (PDF). Архивировано из оригинал (PDF) на 2011-10-01. Получено 2010-10-25.
  22. ^ Росс Дж. Андерсон (2001-03-23). Инженерия безопасности. п. 684. ISBN  0-471-38922-6.
  23. ^ «Microsoft Word для DOS 1.15».

дальнейшее чтение

внешние ссылки