LINUX.ORG.RU

Программа, которая ответит на вопрос «почему»

 


4

5

Результат нескольких лет труда одного паренька: https://github.com/andyjko/whyline

В действии: https://www.youtube.com/watch?v=t6gVZ-qZ4sI

Для Ъ - программа анализирует байткод и записывает трассу Java-приложения таким образом, что потом можно его выполнение крутить взад-вперед и инспектировать состояние переменных - в т.ч. понимать, каким образом мы в данном месте получили именно это значение.

Переворот в отладке? Какому технологическому стеку (помимо java/jvm в данном случае) ещё подвластно подобное? Теоретически, на Smalltalk вполне себе можно замутить. Или на JavaScript. Ещё?

★★★★★

Результат нескольких лет труда одного паренька
программа анализирует байткод и записывает трассу Java-приложения таким образом

waste of time

umren ★★★★★
()

Какому технологическому стеку

simics. там состояние всего компьютера сохраняется или нескольких, если несколько запустить.

dimon555 ★★★★★
()

я такое для перла видел. в начале 200х еще.

anonymous
()

Какому технологическому стеку

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

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

Для справки - фронтенд х86 питуха умеет в 4инструкции за такт - бекенд уже в районе 10. Одна инструкция - это пусть даже байт 10 - т.е. 40байт за такт, либо 40гигабайт на гигагерц, т.е. в районе сотни гигабайт в секунду, даже если взять ipc в районе одного - это десятки гигабайт в секунду с ведра - куда ты их будешь писать?

А собрать трейс функций, когда там 10-20 cps - ну этим можно только подтереться. В гдб вроде есть обратная отладка, но там буфера хватает на одну секунду.

Просто трейс функций - это делается за 5минут на llvm, только никому это не надо, ибо функции отлаживать как? Как разбираться в гигабайтах этих логов? Да и замедлять это будет программу в сотни/тысячи/сотни тысяч раз. Кому оно надо?

registrant27492
()
Ответ на: комментарий от yoghurt

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

Проблема в том, что такие хелворды отлаживать не имеет смысла, а вот то, что имеет смысл отлаживать - для него эти методы не работают.

registrant27492
()

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

Сейчас популярна разработка, ведомая тестами. Отладка в этой концепции просто не нужна.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Сейчас популярна разработка, ведомая тестами. Отладка в этой концепции просто не нужна.

Секундочку! В классическом ТДД-окружении, ну, из которого ноги растут в нынешний мейнстрим, программирование в дебаггере есть неотъемлемая составляющая процесса разработки:

Написал тест > он упал с исключением > открылся дебаггер > дописываем недостающее / меняем имеющееся прямо на месте.

yoghurt ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

А кто-нибудь реально юзает (ну, кроме авторов и мозиллы)? Я всё по-старинке в gdb сижу.

yoghurt ★★★★★
() автор топика

Что-то я по ходу реально из бункера выбрался. Спасибо, прояснили :)

Но в целом подход с why весьма интересен, как развитие уже имеющихся вышеупомянутых вещей.

yoghurt ★★★★★
() автор топика
Ответ на: комментарий от yoghurt

он упал с исключением

Тест бы исполнялся 2часа вместо одной минуты. Ну это как минимум, если это только трейс.

открылся дебаггер

И тут же обделался от десятков гигов логов.

дописываем недостающее / меняем имеющееся прямо на месте

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

Скорее всего в этом днище реализована не отладка, а трейс именно инпутов, ибо отладка на жабке - это невозможно. Трейс инпутов не позволяет тебе ничего, кроме как воссоздать контекст. Но трейс инпутов работает так же только для хелвордов - у него есть 2проблемы:

а) так как это не контекст - восстановление его работает через повторное исполнение программы, либо можно на втором исполнении уже собирать трейс именно кода за последние N-вызово/инструкций.

б) Собственно он никак не позволяет тебе отладить твой код. Ну упал у тебя на определённом иннпуте - дальше что? Это тебе покажет тупо стектрейс(+кора) - зачем нужны эти куллстори. Ну узнал ты что 10тысяч строк падает на «ko-ko-ko» - что дольше? Так же будешь дрюкать step.

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

registrant27492
()
Ответ на: комментарий от registrant27492

Не, ты не понял, я говорю о смолток-среде, где никаких трейсов нет и тесты отрабатывают своё обычное время (без оверхеда).

yoghurt ★★★★★
() автор топика
Ответ на: комментарий от yoghurt

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

А открыть/редактировать код без фичей - это свойство примитивности языка, примитивности задач, которые решаются на нём и прочее. Динамические языки позволяют тебе узнать их структуру в рантайме - на то они и динамические. Это стоит оверхеда, ибо он в сотни раз медленнее статического языка. Это стоит невозможности статического анлиза, вменяемого синтаксиса и любых других фичей статического языка, который позволяет писать сложный код.

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

Жабка всё таки какой-никакой статический язык - это другой мир.

registrant27492
()
Ответ на: комментарий от yoghurt

Ты бы хоть видосик посмотрел

«хоть»? Ъ по ссылкам на текст-то не ходят, за видео вообще доплачивать надо.

t184256 ★★★★★
()
Ответ на: комментарий от registrant27492

Нельзя. Чтобы восстановить всё - тебе надо сохранять контекст на каждую инструкцию

Достаточно запоминать, что изменяют обратимые операции. Имея программный код (а он всегда у дебагера есть) и логи «стоков», можно из любого состояния программы вернуться назад в любую точку.

anonymous
()
Ответ на: комментарий от anonymous

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

Тем более не в любую, а только на начало этих самых «операций», ибо далее - ты ничего не знаешь. В конечном итоге твои потуги просто не работают.

Давай я тебе объясню почему нельзя - ты собрал инпут какой-то - далее ты не знаешь по какому пути пойдёт программа - ты знаешь только куда она придёт. У тебя там 100500 ифов и хрен ты поставишь где-то брейкпоинт, либо как я уже выше писал - будешь дрюкать некст, но это будет та же самая обычная отладка - последовательная.

В конечном итоге даже трейс всех инпутов ничего не даёт - он даёт тогда, когда он работает - т.е. у тебя упало что-то - ты увидел трейс. А когда ты отлаживаешь - ты итак знаешь как ты дошел до текущего состояния.

Ну и по поводу кода - дебаген не имеет никакого кода, ибо от имения кода нужно не просто его наличие - его наличие есть всегда, а собственно понимание этого кода. Т.е. какая информация по его структуре и прочее - тогда можно как-то вывести пути/ключевые места для облегчения ручного режима, но никакие дебагеры не обладают даже примитивным анализом кода.

registrant27492
()
Ответ на: комментарий от anonymous

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

Остальное, в твоём понимании, это наверное какие-то вычисления и прочее, но открою тебе тайну - код жабистов, да и любой код обслуживающий какую-то примитивную логику - он на 90% состоит из долбление в память - т.е. махинации со своими структурами. Ну не сохранишь ты a * b + c - будет только рид - один хрен гигабайты в секунду.

registrant27492
()
Ответ на: комментарий от registrant27492

Для справки - фронтенд х86 питуха умеет в 4инструкции за такт - бекенд уже в районе 10. Одна инструкция - это пусть даже байт 10 - т.е. 40байт за такт, либо 40гигабайт на гигагерц

Я вот хуею, откуда у царя такие мерила скорости: байты за такт или инструкции за такт? Когда они грузятся с разной скоростью, декодируются с разной скоростью (в зависимости от наличия префиксов, например), а исполняются и подавно с разной скоростью (хотя бы в зависимости от того, какие инструкции вокруг них).

anonymous
()
Ответ на: комментарий от anonymous

Достаточно запоминать, что изменяют обратимые операции.

А где их взять, обратимые операции?

anonymous
()

Хотя тут я как царь, не очень понимаю как это работает, и какая при этом будет скорость

anonymous
()

В Elm есть time-travelling debugger.

Miguel ★★★★★
()

That said, at the time of writing this readme, it's 2016, eight years later, and I'm on sabbatical. It's about time I open source this thing and let the community more easily access and replicate the work!

Заопенсорсить через 8 лет? Это никому не нужно. Зачем ты это сюда принёс? На что ты вообще надеялся?

Adonai ★★★
()
Ответ на: комментарий от registrant27492

Тест бы исполнялся 2часа вместо одной минуты. Ну это как минимум, если это только трейс.

Нет. Выше ссылка на rr. Пепрестань уже выдавать свойц мозговой сок за истину.

tailgunner ★★★★★
()

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

Интересно было бы почитать диссер этого чувака, но пока лень :)

buddhist ★★★★★
()
Ответ на: комментарий от basp

Я помню, да. У меня за нехваткой времени всё встало где-то с год назад, но я не теряю надежд)

yoghurt ★★★★★
() автор топика

если я правильно понимал, что делал, когда писал на c#, то в вижалстудии можно идти назад по c# коду

unt1tled ★★★★
()
Ответ на: комментарий от tailgunner

The overhead of rr depends on your application's workload. On Firefox test suites, rr's recording performance is quite usable. We see slowdowns down to ≤ 1.2x. A 1.2x slowdown means that if the suite takes 10 minutes to run by itself, it will take around 12 minutes to be recorded by rr. However, overhead can vary dramatically depending on the workload. For mostly-single-threaded programs, rr has much lower overhead than any competing record-and-replay system we know of.

However, overhead can vary dramatically depending on the workload

может царь и перегнул с цифрами, но в целом чудес не бывает, лол

anonymous
()
Ответ на: комментарий от unt1tled

Да и в gdb можно назать ходить, но тут фишка-то больше в объяснительном анализе трассы

yoghurt ★★★★★
() автор топика

Результат нескольких лет труда одного паренька

Паренёк - маньяк

Переворот в отладке

Лучше отладочной печати всё равно ничего не придумали до сих пор :-/

ei-grad ★★★★★
()
Ответ на: комментарий от anonymous

потому как трейс снимается извне и обрабатывается на хосте (даже с привелечением симулятора инструкций), в то время как в треде обсуждается self-hosted отладка.

How does context tracking work?
...
At the same time it is also desirable to be able to track the changes of variables, memories and registers. There are various strategies available for this. The changes can be followed relatively easily by using the write and read cycles recorded in the trace memory. However, this only functions for internal memories if the CPU shows complete information about these accesses. Even then information about register transfers is not usually available. An exception to this is the C166 family which makes all information about internal operations visible externally via the bondout busses.
Another alternative is to use an instruction set simulator which effectively allows the individual instructions to be executed again. This enables registers and memory states to be recreated more easily. Instruction set simulators are available for PowerPC, 68K, 68HC05, 68HC08, 68HC11, 68HC12, 68HC16, SH2 and the ARM7.

anonymous
()
Ответ на: комментарий от anonymous

в треде обсуждается self-hosted отладка

я вообще к этому написал

However, overhead can vary dramatically depending on the workload

про self-hosted никто ничего не говорил :)

From this starting point the program steps previously recorded in real-time in the trace memory can be debugged again in TRACE32 PowerView GUI.

anonymous
()
Ответ на: комментарий от anonymous

а ничего что это самое

However, overhead can vary dramatically depending on the workload

цитата со странички self-hosted инструмента? треднечитай@сразуотвечай

previously recorded in real-time

ударение подправил :)

anonymous
()

Программа, которая ответит на вопрос «почему»

Ожидал аналог «Великого думателя», а тут дебагер просто...

Deleted
()
Ответ на: комментарий от anonymous

может царь и перегнул с цифрами, но в целом чудес не бывает, лол

Ну да, ошибся на порядок, делов-то. Царю можно.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

anonymous
()
Ответ на: комментарий от anonymous

почему на порядок а не, скажем, на два?

Это я ошибся - именно 2 порядка (slowdown 1.2 и 120мин против 1мин).

царь ведь не указывал какой тест, верно же?

Когда он или кто-то из его свиты укажет - может быть, продолжим разговор.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

лол, я ж и говорю, лапоть влево лапоть вправо... после такого промаха в порядках, допустимо ли считать что теперь уже ты пытался «выдавать свой мозговой сок за истину»?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.