Запись в журнале компьютера Mark II с изображением моли, приклеенной к странице.
Термин «баг » в значении «дефект» появился как минимум в 1878 году, когда Томас Эдисон обозначил «небольшие неисправности и трудности» в своих изобретениях как «баги».
Популярная история из 1940-х годов принадлежит адмиралу Грейс Хоппер . [1] Когда она работала над компьютером Mark II в Гарвардском университете, ее коллеги обнаружили моль , застрявшую в реле, которая мешала работе, и записали в бортовом журнале: «Первый реальный случай обнаружения ошибки». Хотя, вероятно, это шутка , объединяющая два значения слова bug (биологический и дефект), история указывает на то, что этот термин использовался в компьютерной сфере в то время.
Аналогично, термин отладка использовался в аэронавтике до того, как появился мир компьютеров. В письме Дж. Роберта Оппенгеймера , директора Манхэттенского проекта по атомной бомбе во время Второй мировой войны в Лос-Аламосе, этот термин использовался в письме доктору Эрнесту Лоуренсу в Калифорнийском университете в Беркли от 27 октября 1944 г. [2] относительно набора дополнительного технического персонала. В статье Оксфордского словаря английского языка для отладки термин отладка используется в отношении испытаний двигателей самолетов в статье 1945 г. в Журнале Королевского авиационного общества. Статья в "Airforce" (июнь 1945 г., стр. 50) относится к отладке камер самолетов.
Основополагающая статья Гилла [3], опубликованная в 1951 году, является самым ранним подробным обсуждением ошибок программирования, но в ней не используются термины «ошибка» или «отладка» .
В цифровой библиотеке ACM термин «отладка» впервые использован в трех работах с Национальных собраний ACM 1952 года. [4] [5] [6] В двух из трех работах термин используется в кавычках.
К 1963 году отладка стала настолько распространённым термином, что его упоминали вскользь без пояснений на странице 1 руководства CTSS . [7]
Объем
Поскольку программное обеспечение и электронные системы в целом стали более сложными, различные общие методы отладки расширились за счет большего количества методов обнаружения аномалий, оценки воздействия и планирования исправлений программного обеспечения или полных обновлений системы. Слова «аномалия» и «несоответствие» можно использовать как более нейтральные термины , чтобы избежать слов «ошибка» и «дефект» или «баг», где может подразумеваться, что все так называемые ошибки , дефекты или баги должны быть исправлены (любой ценой). Вместо этого можно провести оценку воздействия , чтобы определить, будут ли изменения для устранения аномалии (или несоответствия ) экономически эффективными для системы, или, возможно, запланированный новый выпуск может сделать изменение(я) ненужным. Не все проблемы в системе являются критически важными для безопасности или миссии . Кроме того, важно избегать ситуации, когда изменение может быть более расстраивающим для пользователей в долгосрочной перспективе, чем жизнь с известной(ыми) проблемой(ами) (где «лекарство будет хуже, чем болезнь»). Принятие решений о приемлемости некоторых аномалий может помочь избежать культуры мандата «нулевых дефектов», когда люди могут поддаться искушению отрицать существование проблем, чтобы результат выглядел как нулевые дефекты . Принимая во внимание сопутствующие вопросы, такие как оценка влияния затрат и выгод, более широкие методы отладки будут расширяться для определения частоты аномалий (как часто происходят одни и те же «ошибки»), чтобы помочь оценить их влияние на всю систему.
Инструменты
Отладка на игровых консолях обычно выполняется с помощью специального оборудования, такого как это отладочное устройство Xbox, предназначенное для разработчиков.
Отладка варьируется по сложности от исправления простых ошибок до выполнения длительных и утомительных задач по сбору данных, анализу и планированию обновлений. Навыки отладки программиста могут быть основным фактором в способности отлаживать проблемы, но сложность отладки программного обеспечения сильно зависит от сложности системы, а также в некоторой степени от используемых языков программирования и доступных инструментов, таких как отладчики . Отладчики — это программные инструменты, которые позволяют программисту контролировать выполнение программы, останавливать ее, перезапускать, устанавливать точки останова и изменять значения в памяти. Термин отладчик также может относиться к человеку, который выполняет отладку.
Как правило, языки программирования высокого уровня , такие как Java , упрощают отладку, поскольку обладают такими функциями, как обработка исключений и проверка типов , которые облегчают обнаружение реальных источников неустойчивого поведения. В таких языках программирования, как C или ассемблер , ошибки могут вызывать скрытые проблемы, такие как повреждение памяти , и часто бывает трудно увидеть, где возникла первоначальная проблема. В таких случаях могут потребоваться инструменты отладчика памяти .
В определенных ситуациях могут быть очень полезны универсальные программные инструменты, которые по своей природе являются языково-специфичными. Они принимают форму инструментов статического анализа кода . Эти инструменты ищут очень конкретный набор известных проблем, некоторые из которых распространены, а некоторые редки, в исходном коде, концентрируясь больше на семантике (например, потоке данных), а не на синтаксисе, как это делают компиляторы и интерпретаторы.
Для различных языков существуют как коммерческие, так и бесплатные инструменты; некоторые утверждают, что способны обнаруживать сотни различных проблем. Эти инструменты могут быть чрезвычайно полезны при проверке очень больших исходных деревьев, где непрактично выполнять сквозной анализ кода. Типичным примером обнаруженной проблемы может быть разыменование переменной, которое происходит до того, как переменной будет присвоено значение. В качестве другого примера, некоторые такие инструменты выполняют строгую проверку типов, когда язык этого не требует. Таким образом, они лучше обнаруживают вероятные ошибки в коде, который синтаксически верен. Но эти инструменты имеют репутацию ложных срабатываний, когда правильный код помечается как сомнительный. Старая программа lint для Unix является ранним примером.
Процесс отладки обычно начинается с определения шагов для воспроизведения проблемы. Это может быть нетривиальной задачей, особенно с параллельными процессами и некоторыми Heisenbugs , например. Конкретная пользовательская среда и история использования также могут затруднить воспроизведение проблемы.
После воспроизведения ошибки входные данные программы, возможно, придется упростить, чтобы упростить отладку. Например, ошибка в компиляторе может привести к сбою при разборе большого исходного файла. Однако после упрощения тестового случая для воспроизведения того же сбоя может быть достаточно всего нескольких строк из исходного исходного файла. Упрощение можно выполнить вручную, используя подход « разделяй и властвуй» , при котором программист пытается удалить некоторые части исходного тестового случая, а затем проверяет, сохраняется ли проблема. При отладке в графическом интерфейсе программист может попробовать пропустить некоторое взаимодействие с пользователем из исходного описания проблемы, чтобы проверить, достаточно ли оставшихся действий для возникновения ошибки.
После того, как тестовый случай достаточно упрощен, программист может использовать отладчик для проверки состояний программы (значений переменных, а также стека вызовов ) и отслеживания источника проблемы(проблем). В качестве альтернативы можно использовать трассировку . В простых случаях трассировка представляет собой всего несколько операторов печати, которые выводят значения переменных в определенных точках во время выполнения программы. [ необходима цитата ]
Техники
Интерактивная отладка использует инструменты отладчика, которые позволяют обрабатывать выполнение программы пошагово и останавливать ее для проверки или изменения ее состояния. Подпрограммы или вызовы функций обычно могут выполняться на полной скорости и снова останавливаться при возврате к вызывающей стороне, или сами по себе пошагово, или любой комбинацией этих вариантов. Могут быть установлены контрольные точки, которые позволяют выполнять код на полной скорости, который не подозревается в неисправности, а затем останавливаться в точке, которая является таковой. Размещение контрольной точки сразу после конца программного цикла является удобным способом оценки повторяющегося кода. Широко доступны контрольные точки, где выполнение может продолжаться до тех пор, пока не изменится определенная переменная, и контрольные точки, которые заставляют отладчик останавливаться для определенных видов событий программы, таких как исключения или загрузка общей библиотеки.
Отладка или трассировка печати — это процесс наблюдения (в реальном времени или записанные) за операторами трассировки или операторами печати, которые указывают на ход выполнения процесса и прогрессию данных. Трассировка может быть выполнена с помощью специализированных инструментов (например, трассировки GDB) или путем вставки операторов трассировки в исходный код. Последнее иногда называютотладка printf , из-за использования функцииprintfв C. Этот вид отладки включался командой TRON в исходных версиях языкаBASIC,. TRON расшифровывался как «Trace On». TRON заставлял номера строк каждой командной строки BASIC печататься по мере выполнения программы.
Трассировка активности похожа на трассировку (выше), но вместо того, чтобы отслеживать выполнение программы по одной инструкции или функции за раз, отслеживает активность программы на основе общего количества времени, потраченного процессором/ЦП на выполнение определенных сегментов кода. Обычно это представляется как часть времени выполнения программы, потраченного на обработку инструкций в определенных адресах памяти (программы машинного кода) или определенных программных модулях (язык высокого уровня или скомпилированные программы). Если показано, что отлаживаемая программа тратит непропорционально большую часть своего времени выполнения в отслеживаемых областях, это может указывать на неправильное распределение процессорного времени, вызванное неисправной логикой программы, или, по крайней мере, на неэффективное распределение процессорного времени, которое может выиграть от усилий по оптимизации.
Удаленная отладка — это процесс отладки программы, работающей на системе, отличной от отладчика. Чтобы начать удаленную отладку, отладчик подключается к удаленной системе по каналу связи, например, по локальной сети. Затем отладчик может контролировать выполнение программы на удаленной системе и получать информацию о ее состоянии.
Постмортемная отладка — это отладка программы после того, как она уже рухнула . Связанные методы часто включают различные методы трассировки, такие как изучение файлов журнала, вывод стека вызовов при крахе [8] и анализ дампа памяти (или дампа ядра ) рухнувшего процесса. Дамп процесса может быть получен системой автоматически (например, когда процесс завершился из-за необработанного исключения), или с помощью вставленной программистом инструкции, или вручную интерактивным пользователем.
Алгоритм «Волчья ограда»: Эдвард Гаусс описал этот простой, но очень полезный и теперь известный алгоритм в статье 1982 года для Communications of the ACM следующим образом: «На Аляске есть один волк; как его найти? Сначала постройте забор посередине штата, дождитесь, когда волк завоет, определите, с какой стороны забора он находится. Повторяйте процесс только с этой стороны, пока не дойдете до точки, где вы сможете увидеть волка». [9] Это реализовано, например, в системе контроля версий Git как команда git bisect , которая использует вышеуказанный алгоритм для определения того, какой коммит внес конкретную ошибку.
Отладка с записью и воспроизведением — это метод создания записи выполнения программы (например, с помощью бесплатного инструмента отладки rr от Mozilla ; включение обратимой отладки/выполнения), которую можно воспроизвести и отладить в интерактивном режиме. Полезно для удаленной отладки и отладки прерывистых, недетерминированных и других трудновоспроизводимых дефектов.
Отладка с перемещением во времени — это процесс возврата во времени с помощью исходного кода (например, с помощью Undo LiveRecorder ), чтобы понять, что происходит во время выполнения компьютерной программы; позволить пользователям взаимодействовать с программой; изменить историю при желании и посмотреть, как реагирует программа.
Дельта-отладка – метод автоматизации упрощения тестовых случаев. [10] : стр.123
Saff Squeeze – метод изоляции неудач в ходе теста с использованием постепенного встраивания частей неудачного теста. [11] [12]
Отслеживание причинно-следственных связей : существуют методы отслеживания цепочек причин и следствий в вычислениях. [13] Эти методы можно адаптировать для конкретных ошибок, таких как разыменование нулевого указателя. [14]
В отличие от среды разработки программного обеспечения общего назначения, основной характеристикой встроенных сред является огромное количество различных платформ, доступных разработчикам (архитектуры ЦП, поставщики, операционные системы и их варианты). Встроенные системы по определению не являются универсальными: они, как правило, разрабатываются для одной задачи (или небольшого диапазона задач), а платформа выбирается специально для оптимизации этого приложения. Этот факт не только усложняет жизнь разработчикам встроенных систем, но и усложняет отладку и тестирование этих систем, поскольку для разных платформ требуются разные инструменты отладки.
Несмотря на проблему гетерогенности, упомянутую выше, некоторые отладчики были разработаны как коммерчески, так и в качестве исследовательских прототипов. Примерами коммерческих решений являются Green Hills Software , [19] Lauterbach GmbH [20] и MPLAB-ICD от Microchip (для внутрисхемного отладчика). Двумя примерами исследовательских прототипов инструментов являются Aveksha [21] и Flocklab. [22] Все они используют функциональность, доступную на недорогих встраиваемых процессорах, On-Chip Debug Module (OCDM), сигналы которого выводятся через стандартный интерфейс JTAG . Они тестируются на основе того, сколько изменений необходимо внести в приложение, и скорости событий, с которой они могут справиться.
Помимо типичной задачи выявления ошибок в системе, отладка встроенных систем также направлена на сбор информации о рабочих состояниях системы, которая затем может быть использована для анализа системы: поиска способов повышения ее производительности или оптимизации других важных характеристик (например, энергопотребления, надежности, отклика в реальном времени и т. д.).
Анти-отладка
Антиотладка — это «реализация одного или нескольких методов в компьютерном коде, которые препятствуют попыткам обратного проектирования или отладки целевого процесса». [23] Он активно используется признанными издателями в схемах защиты от копирования , но также используется вредоносным ПО для усложнения его обнаружения и устранения. [24] Методы, используемые в антиотладке, включают:
На основе API: проверка наличия отладчика с использованием системной информации
На основе исключений: проверьте, не мешают ли исключения
Блоки процессов и потоков: проверьте, были ли изменены блоки процессов и потоков.
Измененный код: проверка изменений кода, внесенных отладчиком, обрабатывающим программные точки останова.
Аппаратные и регистровые: проверка аппаратных точек останова и регистров ЦП.
Время и задержка: проверьте время, необходимое для выполнения инструкций.
Обнаружение и наказание отладчика [24]
Ранний пример антиотладки существовал в ранних версиях Microsoft Word , где при обнаружении отладчика выводилось сообщение: «Дерево зла приносит горькие плоды. Теперь программа уничтожает дискету», после чего привод гибких дисков издавал тревожные звуки с целью отпугнуть пользователя и отвадить его от повторных попыток. [25] [26]
^ "InfoWorld Oct 5, 1981". 5 октября 1981. Архивировано из оригинала 18 сентября 2019 года . Получено 17 июля 2019 года .
^ "Архивная копия". Архивировано из оригинала 2019-11-21 . Получено 2019-12-17 .{{cite web}}: CS1 maint: archived copy as title (link)
^ S. Gill, Диагностика ошибок в программах на EDSAC. Архивировано 06.03.2020 в Wayback Machine , Труды Лондонского королевского общества. Серия A, Математические и физические науки, том 206, № 1087 (22 мая 1951 г.), стр. 538-554.
^ Роберт В. Д. Кэмпбелл, Эволюция автоматических вычислений. Архивировано 18 сентября 2019 г. в Wayback Machine , Труды национального собрания ACM 1952 г. (Питтсбург), стр. 29–32, 1952 г.
^ Алекс Орден, Решение систем линейных неравенств на цифровом компьютере, Труды национального собрания ACM 1952 года (Питтсбург), стр. 91-95, 1952.
^ Говард Б. Демут, Джон Б. Джексон, Эдмунд Кляйн, Н. Метрополис, Уолтер Орведаль, Джеймс Х. Ричардсон, MANIAC doi=10.1145/800259.808982, Труды национального собрания ACM 1952 года (Торонто), стр. 13-16
^ Совместимая система разделения времени. Архивировано 27 мая 2012 г. в Wayback Machine , MIT Press, 1963 г.
^ EJ Gauss (1982). "Pracniques: The 'Wolf Fence' Algorithm for Debugging". Communications of the ACM . 25 (11): 780. doi : 10.1145/358690.358695 . S2CID 672811.
^ Целлер, Андреас (2005). Почему программы терпят неудачу: руководство по систематической отладке . Морган Кауфманн. ISBN1-55860-866-4.
^ "Кент Бек, Hit 'em High, Hit 'em Low: Regression Testing and the Saff Squeeze". Архивировано из оригинала 2012-03-11.
^ Rainsberger, JB (28 марта 2022 г.). «The Saff Squeeze». The Code Whisperer . Получено 28 марта 2022 г. .
^ Целлер, Андреас (2002-11-01). «Изоляция причинно-следственных цепочек из компьютерных программ». ACM SIGSOFT Software Engineering Notes . 27 (6): 1–10. doi :10.1145/605466.605468. ISSN 0163-5948. S2CID 12098165.
^ Бонд, Майкл Д.; Нетеркот, Николас; Кент, Стивен В.; Гайер, Сэмюэл З.; МакКинли, Кэтрин С. (2007). "Отслеживание плохих яблок". Труды 22-й ежегодной конференции ACM SIGPLAN по системам и приложениям объектно-ориентированного программирования - OOPSLA '07 . стр. 405. doi :10.1145/1297027.1297057. ISBN9781595937865. S2CID 2832749.
^ Ринард, Мартин С. (2008). «Техническая перспектива исправления ошибок программ». Сообщения ACM . 51 (12): 86. doi :10.1145/1409360.1409381. S2CID 28629846.
^ Харман, Марк (2010). «Автоматизированные методы исправления». Сообщения ACM . 53 (5): 108. doi :10.1145/1735223.1735248. S2CID 9729944.
^ ab Gazzola, Luca; Micucci, Daniela; Mariani, Leonardo (2019). «Автоматическое восстановление программного обеспечения: обзор» (PDF) . IEEE Transactions on Software Engineering . 45 (1): 34–67. doi : 10.1109/TSE.2017.2755013 . hdl :10281/184798. S2CID 57764123.
^ "Debugger and real-time trace tools". www.lauterbach.com . Архивировано из оригинала 2022-01-25 . Получено 2020-06-05 .
^ Танкрети, Мэтью; Хоссейн, Мохаммад Саджад; Багчи, Саурабх; Рагхунатхан, Виджай (2011). «Aveksha». Труды 9-й конференции ACM по встраиваемым сетевым сенсорным системам . SenSys '11. Нью-Йорк, штат Нью-Йорк, США: ACM. стр. 288–301. doi :10.1145/2070942.2070972. ISBN9781450307185. S2CID 14769602.
^ Лим, Роман; Феррари, Федерико; Циммерлинг, Марко; Вальзер, Кристоф; Зоммер, Филипп; Бойтель, Ян (2013). «FlockLab». Труды 12-й международной конференции по обработке информации в сенсорных сетях . IPSN '13. Нью-Йорк, штат Нью-Йорк, США: ACM. стр. 153–166. doi :10.1145/2461381.2461402. ISBN9781450319591. S2CID 447045.
^ Шилдс, Тайлер (2008-12-02). "Anti-Debugging Series – Part I". Veracode . Архивировано из оригинала 2016-10-19 . Получено 2009-03-17 .
^ ab "Защита программного обеспечения с помощью антиотладки Майкл Н. Ганьон, Стивен Тейлор, Ануп Гош" (PDF) . Архивировано из оригинала (PDF) 2011-10-01 . Получено 2010-10-25 .
^ "Microsoft Word для DOS 1.15". Архивировано из оригинала 2013-05-14 . Получено 2013-06-22 .
Дальнейшее чтение
Аганс, Дэвид Дж. (2002). Отладка: Девять обязательных правил для поиска даже самых неуловимых проблем программного обеспечения и оборудования. AMACOM. ISBN 0-8144-7168-4.
Blunden, Bill (2003). Программное изгнание: Справочник по отладке и оптимизации устаревшего кода . APress. ISBN 1-59059-234-4.
Форд, Энн Р.; Теори, Тоби Дж. (2002). Практическая отладка в C++. Prentice Hall. ISBN 0-13-065394-2.
Грёткер, Торстен; Хольтманн, Ульрих; Кединг, Хольгер; Влока, Маркус (2012). Руководство разработчика по отладке, второе издание . Createspace. ISBN 978-1-4701-8552-7.
Мецгер, Роберт С. (2003). Отладка мышлением: междисциплинарный подход . Цифровая пресса. ISBN 1-55558-307-5.
Майерс, Гленфорд Дж. (2004). Искусство тестирования программного обеспечения. John Wiley & Sons Inc. ISBN 0-471-04328-1.
Роббинс, Джон (2000). Отладка приложений . Microsoft Press. ISBN 0-7356-0886-5.
Теллес, Мэтью А.; Хси, Юань (2001). Наука отладки . Группа Кориолиса. ISBN 1-57610-917-8.
Востоков, Дмитрий (2008). Анализ дампа памяти. Антология. Том 1. OpenTask. ISBN 978-0-9558328-0-2.
Целлер, Андреас (2009). Почему программы терпят неудачу, второе издание: руководство по систематической отладке . Морган Кауфманн. ISBN 978-0-1237-4515-6.
Пегги Олдрич Кидвелл, «В погоне за неуловимой компьютерной ошибкой», Анналы истории вычислительной техники IEEE, 1998 г.
Внешние ссылки
В Викицитатнике есть цитаты, связанные с отладкой .
В Wikibook Computer Programming Principles есть страница по теме: Отладка
Шаблоны анализа аварийных дампов – подробные статьи по анализу и поиску ошибок в аварийных дампах
Основы отладки – как улучшить свои навыки отладки
Отладка на основе подключаемых модулей для встраиваемых систем
Тестирование и отладка встраиваемых систем – о формировании цифрового ввода – результаты опроса о тестировании и отладке встраиваемых систем, Byte Paradigm (архивировано из оригинала 12 января 2012 г.)
