Дебаггер что это

Дебаггер

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

Ссылки

См. также

• Отладка программы
• Дизассемблер
• GNU Debugger — отладчик программ от проекта Electric Fence
• Sun Studio — среда разработки программного обеспечения, включающая отладчик dbx для ОС Solaris и GNU/Linux
• Microsoft Visual Studio — среда разработки программного обеспечения, включающая средства отладки, от корпорации OllyDbg — бесплатный низкоуровневый отладчик для операционных систем семейства Windows
• Windows
• Windows и GNU/Linux
• TotalView — один из коммерческих отладчиков для UNIX.

Wikimedia Foundation . 2010 .

• Деацетилазу гистонов (HDAC)
• ДеФюнес Луи

Смотреть что такое «Дебаггер» в других словарях:

• дебаггер — сл. программа отладчик для поиска и исправления ошибок (в своих программах) и взлома (чужих) … Hacker’s dictionary
• сосулька — редк. SoftIce (дебаггер, отладчик для операционных систем семейства Windows) ткнуть сосулькой применить дебаггер SoftIce … Словарь компьютерного сленга
• SoftICE — Отладка драйвера Тип отладчик уровня ядра Разработчик NuMega, Compuware … Википедия
• Age of Empires III — Разработчики Ensemble Studios, Big Huge Games Издатель Microsoft Game Studios (PC) MacSoft (Mac) … Википедия
• Описание персонажей аниме «Моя Богиня!» — Эта статья о персонажах. Об аниме и манге см. «Моя Богиня!». Главные герои Кэйити Морисатоnihongo no namae|Кэйити Морисато|森里 螢一|Morisato Keiichi студент Технологического института Некоми и член Мотоциклетного клуба института. Однажды … Википедия
• Список персонажей «Моя богиня!» — Содержание 1 Главные герои 1.1 Кэйити Морисато 1.2 Верданди … Википедия
• Soft-ice — SoftICE Отладка драйвера Тип отладчик уровня ядра Разработчик NuMega, Compuware ОС Windows Версия 4.2.7 … Википедия
• Soft ICE — SoftICE Отладка драйвера Тип отладчик уровня ядра Разработчик NuMega, Compuware ОС Windows Версия 4.2.7 … Википедия
• Softice — Отладка драйвера Тип отладчик уровня ядра Разработчик NuMega, Compuware ОС Windows Версия 4.2.7 … Википедия
• Описание персонажей аниме «Моя Богиня!» — Основная статья: Моя Богиня! 1 Главные герои 1.1 Кэйити Морисато 1.2 Верданди 1.3 Урд 1.4 … Википедия

debugger

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

Синтаксис

debugger;

Примеры

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

function potentiallyBuggyCode()  debugger; // чтобы протестировать работу отладчика, поместите здесь код, заведомо содержащий ошибку > 

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

Спецификация

Specification
ECMAScript Language Specification # sec-debugger-statement

Поддержка браузеров

BCD tables only load in the browser

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

• Debugging JavaScript
• The Debugger in the Firefox Developer Tools

Found a content problem with this page?

• Edit the page on GitHub.
• Report the content issue.
• View the source on GitHub.

This page was last modified on 18 окт. 2023 г. by MDN contributors.

Your blueprint for a better internet.

Значение слова «отладчик»

Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!

Спасибо! Я стал чуточку лучше понимать мир эмоций.

Вопрос: технологически разнородный — это что-то нейтральное, положительное или отрицательное?

Нейтральное
Положительное
Отрицательное

Синонимы к слову «отладчик&raquo

Предложения со словом «отладчик&raquo

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

Понятия со словом «отладчик»

Отла́дчик (деба́ггер, англ. debugger от bug) — компьютерная программа, предназначенная для поиска ошибок в других программах, ядрах операционных систем, SQL-запросах и других видах кода. Отладчик позволяет выполнять трассировку, отслеживать, устанавливать или изменять значения переменных в процессе выполнения кода, устанавливать и удалять контрольные точки или условия остановки и т.д.

Отправить комментарий

Дополнительно

• Как правильно пишется слово «отладчик»
• Цитаты со словом «отладчик» (подборка цитат)
• Перевод слова «отладчик» и примеры предложений (английский язык)
• «Debugger&raquo in a sentence at WordTools.ai (английский язык)

На что способен хороший отладчик

Порой приходится слышать: «Отладчики бесполезны, гораздо целесообразнее иметь дело с логированием и модульными тестами». Подозреваю, что многие из разделяющих такое мнение думают, будто отладчик только и может, что расставлять точки останова на определённых строках, пошагово просматривать код и проверять значения переменных. Притом, что любой годный отладчик действительно всё это может, на самом деле это только верхушка айсберга. Задумайтесь: мы уже вполне можем наткнуться на код, которому около 40 лет; наверняка же с тех пор что-то изменилось?

Tl;dr — в этом эпизоде дедовского нытья вы узнаете, что хороший отладчик поддерживает различные виды точек останова, предлагает широкие возможности визуализации данных, имеет среду REPL для выполнения выражений, может показывать зависимости между потоками и контролировать их выполнение, может подхватывать изменения в исходном коде и применять их без перезапуска программы. Также он может проходить код от конца к началу и перематывать состояние программы до любого момента в истории её выполнения. Можно даже записать весь ход управления программы и визуализировать поток управления и историю потока данных.

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

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

Точки останова, ах, точки останова

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

Указание точек останова по вертикали. Вы знали, что точки останова можно ставить не только на конкретной строке, а в «строке+столбце»? В единственной строке исходного кода содержится множество выражений (например, вызовы функций foo() + bar() + baz()) , то можно поставить точку останова посреди строки и переходить прямо к точке выполнения. Уже некоторое время эта возможность поддерживается в LLDB, но поддержка на уровне IDE может отсутствовать. В Visual Studio есть команда Step into specific (пошаговое выполнение выбранной функции), решающая схожую задачу — позволяет выбрать, в какую функцию войти, если в одной строке кода имеется множество вызовов.

Условные точки останова. Как правило, есть комплект дополнительных опций, которые можно задавать для точек останова. Например, можно указать условие “hit count” (количество совпадений), чтобы точка останова срабатывала только по достижении определённого количества попаданий или после каждой N-ной итерации. Есть даже более мощный феномен, условные выражения, чтобы инициировать точку останова, когда приложение будет в определённом состоянии. Например, можно задать срабатывание точки останова лишь в том случае, когда попадание случается в главном потоке и monster->name == «goblin» . Отладчик Visual Studio также поддерживает условные выражения типа «когда изменится» — инициировать останов, когда значение monster->hp изменится по сравнению с предыдущим случаем попадания в эту точку останова.

Точки трассировки. Но что, если в точках останова программа останавливаться не должна? Без лишних слов, можно не останавливать выполнение, а напечатать сообщение в выводе. И речь не о простом строковом литерале вида “got here lol” (дошли сюда, хаха); сообщение может содержать выражения, например, для вычисления и встраивания значений из программы, скажем, «итерация #, действующий монстр – это имя>». В сущности, мы внедряем вызовы printf в случайных точках нашей программы, не пересобирая и не перезапуская её. Красиво, правда?

Точки останова по данным. Также точки останова необязательно должны находиться на конкретной строке, по адресу или в функции. Во всех современных отладчиках поддерживаются точки останова по данным, то есть, программа может остановиться в тот момент, когда происходит запись в конкретный участок памяти. Не можете понять, почему монстр внезапно погибает? Задайте точку останова по данным в monster->hp и получайте уведомление всякий раз, когда это значение изменится. При отладке это особенно помогает в случаях, когда некоторый код пишет информацию в ту область памяти, в которую писать не должен. Сочетайте эту практику с выводом сообщений в консоль, и получится мощный механизм логирования, чьи возможности несравнимы с printf!

Визуализация данных

Ещё одна элементарная отладочная возможность — проверка данных (data inspection). Любые отладчики могут показывать значения переменных, но в хороших отладчиках предлагаются широкие возможности для создания собственных визуализаторов. В GDB есть инструменты структурной печати (pretty printers), в LLDB — инструменты форматирования данных, а в Visual Studio есть NatVis. Все эти механизмы весьма гибкие, и с их помощью вы можете при визуализации объектов делать практически что угодно. Эта возможность бесценна при проверке сложных структур данных и непрозрачных указателей. Например, не приходится беспокоиться о внутреннем представлении хеш-таблицы, будет достаточно просмотреть список записей «ключ/значение».

Эти визуализаторы исключительно полезны, но хорошие отладчики способны даже на большее. Если у вас есть GUI, зачем же ограничиваться «текстовой» визуализацией? Отладчик может показывать таблицы с данными и диаграммы (например, результаты SQL-запросов), отображать картинки (например, иконки или текстуры), воспроизводить звуки и многое другое. Здесь графический интерфейс открывает безграничные возможности, и такие варианты визуализации даже не очень сложно реализовать.

Вычисление выражений

В большинстве современных отладчиков поддерживается вычисление выражений. Идея такова: можно ввести выражение (как правило, на том же языке, на котором написана ваша программа), и отладчик интерпретирует его, воспользовавшись состоянием программы в качестве контекста. Например, вы вводите monsters[i]->get_name() , и отладчик показывает вам «goblin» (где monsters и i – это переменные в текущей области видимости). Очевидно, это огромное минное поле, и реализация может значительно отличаться в разных отладчиках и на разных языках.

Например, отладчик Visual Studio для C++ реализует достаточно широкое подмножество C++ и рассчитан даже на вызовы функций (с некоторыми ограничениями). Применяемый в нём подход основан на использовании интерпретатора, так что этот отладчик весьма быстр и «безопасен», но не позволяет выполнять по-настоящему произвольный код. То же самое делает GDB. С другой стороны, LLDB использует настоящий компилятор (Clang), при помощи которого собирает выражение вплоть до машинного кода, а затем выполняет его в программе (хотя, в некоторых случаях может применять интерпретацию в качестве оптимизации). Таким образом удаётся выполнять практически любой действительный C++!

(lldb) expr Enter expressions, then terminate with an empty line to evaluate: 1: struct Foo < 2: int foo(float x) < return static_cast(x) * 2; > 3: >; 4: Foo f; 5: f.foo(3.14); (int) $0 = 6

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

Конкурентность и многопоточность

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

Например, отличный пример, в котором отладчик может сэкономить вам массу времени — отладка взаимных блокировок. Если вам удалось поймать ваше приложение в состоянии взаимной блокировки, то вам повезло! Хороший отладчик покажет все стеки вызовов для всех потоков, а также зависимости между ними. Не составляет труда увидеть, какие потоки дожидаются каких ресурсов (например, просмотреть мьютексы), и кто эти ресурсы отжирает. Некоторое время назад автор написал статью об отладке взаимных блокировок в Visual Studio, можете сами убедиться, насколько это просто.

Очень распространённая проблема при разработке и отладке многопоточных приложений — в том, что сложно проконтролировать, когда именно выполняются какие потоки и в каком порядке. Многие отладчики придерживаются политики «всё или ничего», то есть, по достижении точки останова стопорится вся программа (т.е., все её потоки). Если нажать “continue” (продолжить), то все потоки снова запустятся. Это нормально работает, если потоки у вас в программе не перекрываются, но по-настоящему раздражает, если одни и те же потоки выполняются в разных точках останова, причём попадания в эти точки происходят в случайном порядке.

Хороший отладчик может замораживать и размораживать потоки. Можно выбирать, какие потоки должны выполняться, а какие — спать. В результате очень и очень упрощается отладка сильно распараллеленного кода, а также удаётся эмулировать различные условия гонок и взаимные блокировки. В Visual Studio можно замораживать и растапливать потоки в UI, а в GDB предусмотрен так называемый нон-стоп режим. В RemedyBG есть очень удобный UI, в котором можно быстро переключаться в «соло»-режим и выходить из него (демo, смотреть с 2:00).

Выше я уже упоминал, что отладчики могут показывать зависимости между потоками. Хороший отладчик также поддерживает корутины (зелёные потоки, задачи, т.д.) и предлагает ряд инструментов для визуализации актуального состояния программы. Например, в Visual Studio есть возможность под названием параллельные стеки. В окне «Parallel Stacks» выводится быстрый обзор всего состояния программы, и можно просмотреть, какой код выполняется в различных потоках.

Горячая перезагрузка

Представьте себе, как проходит типичный сеанс отладки. Вы запускаете программу, загружаете данные, выполняете над ними некоторые операции и, наконец, выуживаете баг. Вы шаг за шагом расставляете точки останова и вдруг осознаёте, что конкретное условие “if” написано с ошибкой: в нём должно быть >=, а не >. Что делать дальше? Остановить программу, исправить это условие, пересобрать программу, запустить её, загрузить данные, выполнить некоторые действия… но, подождите. На дворе 2023 год, так что же вы будете делать дальше?

Вы исправите условие и сохраните файл. Пару мгновений — и программа подхватит изменения, внесённые в код! Никакого перезапуска и никакой потери состояния, выполнение возобновится ровно в той точке, в которой выполнение было прекращено. Вы сразу же увидите, что правка была неверной, и на самом деле здесь должно стоять ==. Ещё некоторые исправления — и, вуаля, бага больше нет.

Такая возможность сродни волшебству, и называется она горячая перезагрузка; хороший отладчик может подхватить изменения, внесённые в исходный код, и применить их прямо в выполняемой программе, без перезапуска оной. Многие, кто работает с динамическими языками или языками, завязанными на виртуальные машины (например, JavaScript, Python или Java) знают, насколько это классно, но не каждый осознаёт, что так можно делать и в компилируемых языках, например, в C++ или Rust! Например, Visual Studio поддерживает горячую перезагрузку для C++ при помощи Edit and Continue (Отредактировать и продолжить). Да, здесь есть длинный список ограничений и неподдерживаемых изменений, но во многих распространённых сценариях этот механизм всё равно работает вполне хорошо (демо).

Ещё одна потрясающая технология называется Live++; пожалуй, это наилучшее из имеющихся сегодня решений для перезагрузки. Live++ поддерживает различные компиляторы и системы сборки, может использоваться с любыми IDE или отладчиками. Список неподдерживаемых сценариев здесь гораздо короче, и многие из этих ограничений не фундаментальные: если приложить достаточные усилия, то горячая перезагрузка работает почти с любыми вариантами изменений.

Горячая перезагрузка не сводится к применению изменений в действующей программе. Хорошая реализация горячей перезагрузки может помочь при восстановлении после фатальных ошибок, например при нарушении правил доступа, или поменять уровни автоматизации (и потенциально — любые другие флаги компилятора) для различных модулей компилятора. Это также можно делать удалённо и для множества процессов одновременно. Можете посмотреть следующее экспресс-демо Live++ от @molecularmusing:

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

Путешествие во времени

Вы когда-нибудь сталкивались с такой проблемой: пробираетесь через код и случайно заступили лишнего? Самую чуточку, но, уф, ущерб уже причинён. Хорошо, давайте перезапустим программу и попробуем ещё раз… пробуем снова и после рестарта программы всё хорошо, но… ох. Ничего страшного, давайте попробуем отступить назад несколько раз. Такой приём кажется ещё более волшебным, чем горячая перезагрузка, но хороший отладчик, фактически, позволяет путешествовать во времени. Сделайте всего шаг назад или поставьте точку останова и воспроизводите код в обратном порядке, пока не наткнётесь на неё, то есть, отлаживайте как в 2023, а не в 1998.

Многие отладчики так или иначе поддерживают эту возможность. GDB реализует путешествия во времени, записывая все изменения регистров и памяти, вносимые каждой инструкцией, благодаря чему отмена таких изменений становится тривиальной. Правда, такой подход сопряжён с серьёзными издержками в производительности, так что в неинтерактивном режиме он может быть не слишком практичен. Другой популярный подход основан на следующем наблюдении: большей частью выполнение программы детерминировано. Всякий раз, когда происходит какое-либо недетерминированное событие (системный вызов, операция ввода/вывода, т.д.), можно сделать мгновенный снимок программы, а затем просто реконструировать состояние программы в любой момент, просто перемотав её состояние до ближайшего мгновенного снимка и выполнив код, начиная оттуда. В принципе, именно это и делают UDB, WinDBG и rr.

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

При путешествиях во времени возникают определённые издержки производительности, но в некоторых ситуациях они совершенно оправданы. Из сценариев, в которых они нужны, сразу приходит на ум выполнение тестов. Разумеется, лучше быстрые тесты, чем медленные, но способность воспроизвести и исследовать развитие определённого провала при тестировании исключительно экономит время. Особенно в случаях, когда тест хрупкий, а для воспроизведения теста требуется много времени и везения. На самом деле, инструмент rr был исходно разработан компанией Mozilla для записи и отладки тестов Firefox.

Бывает, что путешествия во времени удаётся реализовать очень эффективно, если они глубоко интегрированы в саму экосистему, и, следовательно, позволяют предвосхищать определённые вещи и сглаживать углы. Например, если большую часть памяти в программе занимают неизменяемые ресурсы, загруженные с диска, то отслеживать их гораздо проще, а мгновенные снимки можно делать очень компактными. Замечательный пример такой интегрированной среды для разработки и отладки — Tomorrow Corporation Tech Demo. Если вы ещё не видели это демо — посмотрите не откладывая!

Всеведущая отладка

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

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

Если я вас ещё не убедил, посмотрите это видео — Debugging by querying a database of all program state от Кайла Хью. В нём по-настоящему хорошо объяснено, как всё это возможно, и почему следует присмотреться к этой возможности. Разумеется, здесь есть ограничения, но многие из них — это просто детали реализации, а не фундаментальные барьеры. Также рекомендую посмотреть видео The State Of Debugging in 2022 от Роберта O’Каллахана (автора rr), где отлично аргументировано, почему за всеведущей отладкой будущее, и почему стоит требовать от наших инструментов большего.

Всеведущая отладка пока в самом начале пути, хотя эта идея была сформулирована уже несколько десятилетий назад (см. Debugging Backwards in Time (2003) от Била Льюиса). Сама идея очень проста, но эффективно и практично реализовать её сложно. Даже при этом потенциал её головокружителен. Отличный образец современного всеведущего отладчика — Pernosco. Список поддерживаемых в нём возможностей и вариантов использования велик, и даже простые демки выглядят почти невероятно. Можете опробовать его сами — и добро пожаловать в будущее!

Ещё один восхитительный инструмент, который стоит попробовать — WhiteBox. Он компилирует, выполняет и «отлаживает» код по мере того, как вы этот код пишете, позволяя вам как следует рассмотреть состояние программы в любой момент времени. Пока он всё ещё в состоянии бета-версии, и мне не терпится увидеть, что же из него получится. Именно таким я хотел бы видеть будущее и уверен, что когда-нибудь мы в нём окажемся :D.

Отлаживать или не отлаживать?

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

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

• Высокая производительность
• Программирование
• Visual Studio
• Отладка