Чому зворотна налагодження використовується рідко? [зачинено]

gdb реалізував підтримку зворотної налагодження у 2009 році (з gdb 7.0). Я ніколи про це не чув до 2012 року. Зараз я вважаю це надзвичайно корисним для певних типів проблем налагодження. Я хотів, щоб я чув про це раніше.

Виправте мене, якщо я не прав, але моє враження, що методика все ще використовується рідко, і більшість людей не знають, що вона існує. Чому?

Чи знаєте ви з будь-яких спільнот програмування, де використання зворотної налагодження є звичайним?

Довідкова інформація:

• Stackoverflow: Як працює зворотна налагодження?
• gdb використовує термін "зворотна налагодження", але інші постачальники використовують інші терміни для однакових або подібних методів:
  • Microsoft називає це IntelliTrace або "Історична налагодження"
  • Існує зворотний налагоджувач Java під назвою Omniscient Debugger , хоча він, мабуть, більше не працює в Java 6
  • Є й інші зворотні налагоджувачі Java
  • Налагоджувач OCaml (ocamldebug) називає це подорож у часі

Для одного, запуск у режимі налагодження із записом увімкнено дуже дорого порівняно з навіть звичайним режимом налагодження; він також споживає набагато більше пам’яті.

Простіше знизити деталізацію з рівня лінії на функціональний рівень виклику. Наприклад, стандартний налагоджувач у затемненні дозволяє "перейти в кадр", що по суті є переходом назад до початку функції із скиданням усіх параметрів (нічого, зроблене на купі, не повертається, і finallyблоки не виконуються , тож це не справжній зворотний налагоджувач; будьте уважні).

Зауважте, що це доступно вже кілька років і працює рука об руку із заміною гарячого коду.

Як уже згадувалося, продуктивність є ключовою, наприклад, при зворотній налагодженні gdb, запуск чогось на зразок gzip бачить уповільнення в 50 000x порівняно із запущеним на робочому місці. Однак існують комерційні альтернативи: я працюю на Undo undo.io , і наш продукт UndoDB робить те саме, але з уповільненням менше 2 рази. Існують і інші комерційні оборотні налагоджувачі.

Для огляду вибору технології та продуктів дивіться серію публікацій у блозі, про які я писав рік тому (та деякі подальші дії з тих пір):

• http://jakob.engbloms.se/archives/1547 - техн
• http://jakob.engbloms.se/archives/1554 - дослідження
• http://jakob.engbloms.se/archives/1564 - продукція
• http://jakob.engbloms.se/archives/1768 - оновлення до попереднього допису

Моє відчуття, чому він використовується так мало, полягає в тому, що для нього потрібне спеціальне обладнання, або спеціальний відладчик, або налаштування системи правильно. На жаль, більшість людей не вкладають час, щоб отримати максимальну цінність від своїх інструментів налагодження.

І той факт, що "дешевий дефолт" gdb майже неприпустимо повільний і має досить багато проблем зі стабільністю для всього, крім найбільш поширених цільових систем.

З мого досвіду як інженера з продажу налагоджувача TotalView, люди знають, що він існує, але вони не вважають, що він працює, незалежно від (прийнятного чи ні) уповільнення.

Нещодавно Кембриджський університет провів опитування під назвою "Неприйняття витрат на зворотну налагодження глобальної економіки $ 41 млрд щорічно" .

І повертаючись до GDB, я чув (багато), що уповільнення робить його досить непридатним для програми "в реальному житті".

Я особисто хотів би почути більше людей, які використовують зворотну налагодження в додатках, окрім "Привіт, світ!"

Я думаю, що важливо трохи розширити цю «зворотну» чи «історичну» налагодження. Я думаю, що розуміти складні системи та поведінку в них, відтворювати "події", які роблять стан явним, абсолютно важливо.

Я хочу висловити те, що ви не самотні задаєтесь питанням, чому ця методика не так сильно застосовується сьогодні або чому пов'язані проблеми рідко чітко обговорюються.

Отже, наголосимо тут на двох дуже важливих поняттях:

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 теж). Тож люди вже сьогодні використовують ці методи, ВЕЛИКІ, щоб зрозуміти складні системи та зробити їх ще кращими. Ось чому вони використовують методи зворотної налагодження.