GDB реализовал поддержку обратной отладки в 2009 году (с GDB 7.0). Я никогда не слышал об этом до 2012 года. Теперь я нахожу это чрезвычайно полезным для определенных типов проблем отладки. Я хотел бы услышать об этом раньше.
Поправьте меня, если я ошибаюсь, но у меня сложилось впечатление, что техника все еще используется редко, и большинство людей не знают, что она существует. Почему?
Знаете ли вы о каких-либо сообществах программистов, где широко используется обратная отладка?
Исходная информация:
- Stackoverflow: как работает обратная отладка?
- GDB использует термин «обратная отладка», но другие поставщики используют другие термины для идентичных или похожих методов:
- Microsoft называет это IntelliTrace или «Историческая отладка»
- Существует обратный отладчик Java под названием Omniscient Debugger , хотя он, вероятно, больше не работает в Java 6.
- Есть и другие обратные отладчики Java
- Отладчик OCaml (ocamldebug) называет это путешествием во времени
Ответы:
Например, работа в режиме отладки с включенной записью очень дорога по сравнению с обычным режимом отладки; это также потребляет намного больше памяти.
Легче уменьшить степень детализации от уровня линии до уровня вызова функции. Например, стандартный отладчик в eclipse позволяет вам «переходить к кадру», что по сути является переходом к началу функции со сбросом всех параметров (ничего не было сделано в куче, и
finallyне выполняются блоки. , так что это не настоящий обратный отладчик, будьте осторожны с этим).Обратите внимание, что это было доступно в течение нескольких лет и работает рука об руку с заменой горячего кода.
источник
Как уже упоминалось, производительность является ключевой, например, с помощью обратимой отладки gdb, при запуске чего-то вроде gzip наблюдается замедление в 50 000 раз по сравнению с естественным запуском. Однако есть коммерческие альтернативы: я работаю на Undo undo.io , и наш продукт UndoDB делает то же самое, но с замедлением менее чем в 2 раза. Есть и другие коммерческие обратимые отладчики.
источник
rr?Для обзора выбора технологий и продуктов см. Серию постов в блоге, которые я написал около года назад (и некоторые последующие действия с тех пор):
Я чувствую, почему он используется так мало, что ему требуется специальное оборудование, или специальный отладчик, или правильная настройка вашей системы. К сожалению, большинство людей не тратят время на получение максимальной отдачи от своих инструментов отладки.
И тот факт, что «дешевый дефолт» gdb почти неоправданно медленен и имеет довольно много проблем со стабильностью для всех, кроме самых распространенных целевых систем.
источник
Из моего опыта работы инженером по продажам в отладчике TotalView люди знают, что он существует, но не думают, что он работает, независимо от (приемлемого или нет) замедления.
Недавно в Кембриджском университете было проведено исследование под названием «Отказ от принятия обратных затрат на отладку для глобальной экономики в 41 миллиард долларов в год» .
Возвращаясь к GDB, я слышал (много), что замедление делает его совершенно непригодным для использования в реальных приложениях.
Лично я хотел бы получить ответ от большего количества людей, использующих обратную отладку в приложениях, отличных от "Hello world!"
источник
Я думаю, что важно немного углубиться в эту «обратную» или «историческую» отладку. Я думаю, что понять сложные системы и поведение в них, воспроизвести «события», которые делают состояние явным, абсолютно необходимо.
Что я хочу выразить, так это то, что вы не одиноки, когда задаетесь вопросом, почему этот метод не так широко применяется сегодня или почему связанные проблемы редко обсуждаются четко.
Итак, давайте подчеркнем две очень важные концепции здесь:
1. Для понимания системы программирования полезно сделать явное состояние
2. Чтобы еще лучше понять систему программирования, воспроизведение последовательности состояний (событий) может очень помочь.
Вот некоторые источники, которые занимались проблемой и предлагали или разрабатывали решения для этой проблемы (работа с состоянием в сложных системах):
-Вне смолки, бумага: http://shaffner.us/cs/papers/tarpit.pdf Основные идеи: избегать, изолировать или сделать состояние явным
-CQRS http://www.cqrs.nu/ Это сочетание двух концепций: сегрегация командных запросов и источников событий. Существуют разные реализации (Java, C #, Scala). Воспроизведение последовательностей Тейта и развитие модели предметной области являются решающими частями здесь.
Если вы действительно уменьшаете масштаб и видите очень широкую картину, вы уже можете видеть, что с «ростом» функционального программирования люди уже ((не) сознательно) притягиваются к fp, потому что это делает состояние явным! Но это относится только к первому пункту: для решения второго нужен еще один концепт, который можно «свободно» описать как функциональное реактивное программирование.
Таким образом, вы можете сказать все хорошо, но кто на самом деле использует CQRS и FRP? Я бы сказал (IMO, потому что у меня нет конкретных цифр), на самом деле, многие компании просто не знают, какая у них работа, эта терминология. Может быть, вы немного погуглили и узнали от предприятий, которые используют CQRS, уже есть истории успеха. FRP тоже медленно растет в качестве примера, который я мог бы привести Netflix: http://techblog.netflix.com/2013/02/rxjava-netflix-api.html, который только что выпустил реализацию RX, которая на самом деле основана на .NET (но имеет реализация Javascript тоже). Таким образом, люди уже сегодня используют эти методы, БОЛЬШОЙ, чтобы понять сложные системы и сделать их еще лучше. Вот почему они используют методы обратной отладки.
источник