Как стать автором
Обновить

Комментарии 10

Точки останова по данным - классная штука, но почему-то до сих пор в Visual Studio не добавили такую простую возможность, как установка точки по данным из контекстного меню окон просмотра переменных (Locals, Watch). Приходится вбивать выражение с "&" (с адресом переменной) и затем вручную вбивать этот адрес в шестнадцатеричном виде в окно установки точки по изменению данных.

Right click->Break when value changes?

А окно установки дата-бряка вполне понимает &var

Главное, что должен уметь хороший отладчик - не исполнять НИКАКОГО кода отлаживаемого приложения без явного желания оператора

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

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

в конфиге программы есть настройка "отладочный режим"

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

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

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

Так что иногда проще с трассировкой "Лол, мы сюда попали %потому что%".

Жалко что почти нет прогресса по части низкоуровневой отладки на тех же x86/arm. Понятно, что там все упирается в архитектурные особенности, но производители мало что добавляют/улучшают в части отладки, а то немногое что все же потихоньку шлифуют очень нескоро попадает в какие-либо основные софтовые отладчики. Конечно для микроконтроллеров есть всякие jtag, но я говорю именно про софтовую низкоуровневую отладку встроенными в процессор средствами. Вот и получается, что лучший отладчик - это голова на плечах да плюс хорошие знания платформы :)

Наличие hot reload в плюсах стало для меня открытием, спасибо за хорошую статью :)

Никто не сталкивался с тем, что natvis, внедренный в .pdb, не подхватывается в студии при отладке другого приложения, собранного с такой .dll и ее .pdb, лежащего рядом?

Несколько раз пробовал разобраться как пользоваться отладчиком, но так и не понял в чем смысл.

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

Интересно для чего и на чем вы пишете. Из моего опыта C#, немного плюсов, Stm32 и rp2040 я не замечал значительной разницы между сборкой и запуском просто так и под отладчиком

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории