Здравствуйте, SkyDance, Вы писали:

SD>У логгера есть только одна проблема — ту, что еще тов. Гейзенберг описал. Гугли принцип неопределенности:
SD>включая логирование, ты воздействуешь на процесс исполнения. Никогда не сталкивался с вариантом,
SD>когда с логами все работает, без — нет?
по хорошему логгирование работает всегда в кольцевой буфер в зашаренной памяти, а оттуда его выгребают или не выгребают.

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

дайте пример, когда отладчик действительно полезен и незаменим.

Здравствуйте, SkyDance, Вы писали:

М>>логи покрывают все баги отладчика, а отладчик покрывает возможности лога только частично

SD>Короче говоря. Это два разных инструмента. Логи, это как посмертное вскрытие — можно констатировать, что пациент 16.09.2011 заболел триппером, вылечился 25.09.2011, а 14.03.2012 упал в канализационный люк и умер. Дебаггер и crash dump (при умелом использовании) тебе покажет видеосъемку, как пациент шел по улице, смотрел на грудь проходившей мимо женщины, не увидел открытый люк, и упал в него. Потом умер.

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

У отладчика есть один критический недостаток: лично в моем случае он доступен хорошо если в 10-20% случаев. А после того как привык оперировать логами, действительно приходишь к выводу о том, что тесты + логи покрывают 99% задач связанных с отладкой.

Я вообще-то писал, что отладчик в eclipse cdt вполне себе работает. И да, в моих условиях задержка на бряк приводила к разрыву соединения, и от того был лог в stderr и бряк в тяжелых случаях. Того кода C-го была тонкая прослойка между os api и java. Опять таки- жаба (python, scala, нужное подставить) в eclipse отлично отлаживается.
Imho любой интерактивный отладчик- это костыли, чтобы любой условный индус мог таки написать код, проблема только что не всегда отладка по брякам возможна. В особенности поразительно, как SkyDance умудряется по-живому отлаживать сетевой стек.

Здравствуйте, kaa.python, Вы писали:

KP>У отладчика есть один критический недостаток: лично в моем случае он доступен хорошо если в 10-20% случаев.
как интересно. в моем случае тоже, т.к. приходится писать встраиваемые системы на никсах, причем доступа к самой системе у меня нет, т.к. нет допуска и потому на моей стороне возможности отладки ограничены (не говоря о том, что у меня нет набора реальных данных для тестов и данные приходится генерировать от балды). что там можно отладить? одна из ошибок была связана с утечкой памяти в результате ее фрагментации и это проявлялось только в реальной системе на полной загрузке и далеко не сразу, а когда последовательность запросов на выделение буферов была такой, что... ну в общем там сначала выделяется блок для быстрой проверки, а затем блок для дополнительной проверки. первый блок обычно освобождается быстрее, а второй блок -- большего размера. и все это в многопоточной системе. и проявляется только в определенных комбинациях размеров буферов, кол-ва потоков и кол-ва физических ядер.

вот такая реальная задача из реальной жизни. а под отладчиком все шоколадно. выделяем блок за блоком и освобождаем как можно быстрее. никакие утилиты для поиска течи памяти эту течь не показывают.

так же на никсах активно используются очень разные языки. отдельные функи на си, а на питоне "клей", а различные компоненты сношаются через XML-RPC, который пишется на чем-то очень сильно высокоуровневом. на самом высоком уровне все крутится в четырех волшебных словах GET, POST, PUT, DELETE (get_obj, add_obj, update_obj, free_obj), а путь на низ небыстрый и через кучу слоев абстракции.

какой отладчик может с этим работать?

Здравствуйте, ArtemGorikov, Вы писали:

AG> В особенности поразительно, как SkyDance умудряется по-живому отлаживать сетевой стек.



да что там сетевой стек. возьмем простую машину состояний, в которой есть табличка с данными, указывающая из какого состояния в какое переходить при каких символах на входе. как это отлаживать?! как точки останова ставить? да и куда? там же нет кода в прямом смысле этого слова. пусть у нас есть Aho–Corasick и есть набор паттеронов. и входные данные. допустим, достоверно известно, что во входных данных есть заданный паттерн, но он не обнаруживается. а если удалить все паттерны, кроме данного -- тогда все ок.

чем поможет отладчик?! смотреть как строиться дерево, конечно, прикольно, вот только сильно утомительно, а паттернов у нас сто тыщ миллионов. и в каком месте косяк? а косяк может быть как на этапе построения дерева, так и на этапе поиска паттерна. пускай отладчик показывает, что сейчас из состояния A мы переходим в состояние B из которого уже не выходим обратно в состояние A и потому... блин, это не баг, это баго-фича. не найти "ама" в строке "мама", при условии, что у нас есть паттерны "ама" и "мама". ну вот маму мы нашли, а вот аме не повезло. а могло бы и повезти.

вообще, машины состояний очень тяжело отлаживать и они требуют написания своих собственных дебаггеров/логеров.

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

хорошо, когда вы можете запустить программу прямо в среде разработки. а если это программа для web-Сервера и там cgi? как бы нетривально запустить ее под интерактивным отладчиком на сервере. ну то есть, конечно, вызвать-то отладчик можно и начать отлаживать, но даже программу "как тебя зовут?", "вася", "привет, вася!" хрен отладишь, даже без учета тайм-аутов, т.к. сначала нас вызывают, чтобы мы спросили имя. потом нас вызывают еще раз, с именем в теле POST'а, затем еще раз взывают, чтобы ранее переданное имя вы склеили со строкой "привет, ". на уровне интерактивного отладчика тут нет интерактивности.

Здравствуйте, SkyDance, Вы писали:

SD>Порой ты вроде разумно пишешь.
Увы чем дальше тем реже. Всё больше про секас и нигеров.

SD>Мне логгер еще ни разу не позволил вернуть IP (который регистр, а не адрес) назад и _с текущими переменными_ еще раз выполнить по шагам вот эту функцию. Про принцип неопределенности я уже писал — включенное логирование изменяет поведение программы.
А ещё логгинг не даёт возможности в определённый момент по результатам анализа состояния пропустить кусок кода, поменять значение переменных, чтоб выполнение пошло иначе. И прочая и прочая.

SD>Короче говоря. Это два разных инструмента. Логи, это как посмертное вскрытие — можно констатировать, что пациент 16.09.2011 заболел триппером, вылечился 25.09.2011, а 14.03.2012 упал в канализационный люк и умер. Дебаггер и crash dump (при умелом использовании) тебе покажет видеосъемку, как пациент шел по улице, смотрел на грудь проходившей мимо женщины, не увидел открытый люк, и упал в него. Потом умер.
+100

Здравствуйте, kaa.python, Вы писали:

KP>У отладчика есть один критический недостаток: лично в моем случае он доступен хорошо если в 10-20% случаев. А после того как привык оперировать логами, действительно приходишь к выводу о том, что тесты + логи покрывают 99% задач связанных с отладкой.
Ну, 99% это сильно завышено.
Зато логи + отладчик покрывают существенно больше.

Здравствуйте, мыщъх, Вы писали:

SD>>У логгера есть только одна проблема — ту, что еще тов. Гейзенберг описал. Гугли принцип неопределенности:
SD>>включая логирование, ты воздействуешь на процесс исполнения. Никогда не сталкивался с вариантом,
SD>>когда с логами все работает, без — нет?
М>по хорошему логгирование работает всегда в кольцевой буфер в зашаренной памяти, а оттуда его выгребают или не выгребают.
Ага, плавали знаем. Чуть чуть быстрее говна посыпалось в лог и опа, не успели выгрести и теперь ценность лога стремится к нулю.

М>а что отладочный процесс это вообще другой процесс -- это не мешает? не говоря уже о воздействии самого отладчика.
Отладчики разные бывают. В идеале при остановке по отладке останавливается сразу вся виртуальная машина, в которой крутится отлаживаемый софт. Но такое далеко не всегда надо, даже для системного софта.

М>с вами все ясно.
Кто бы говорил, ага.

Здравствуйте, мыщъх, Вы писали:

KP>>У отладчика есть один критический недостаток: лично в моем случае он доступен хорошо если в 10-20% случаев.
М>как интересно. в моем случае тоже, т.к. приходится писать встраиваемые системы на никсах, причем доступа к самой системе у меня нет, т.к. нет допуска и потому на моей стороне возможности отладки ограничены (не говоря о том, что у меня нет набора реальных данных для тестов и данные приходится генерировать от балды). что там можно отладить?

Ну так и говори: отладчика в моих условиях нету.
А то рассказываешь тут про вкус устриц тем, кто их ест постоянно.

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

Так бы сразу и написал — дебаггера у тебя нет, поэтому тебе он не нужен

Логи, даже те, которые пишутся в эти самые mmap'ы, _ВСЕ_РАВНО_ меняют поток исполнения по сравнению с их отсутствием. Банально сбивают тайминги. Дебаггер полностью останавливает виртуальную машину (всю vmware'ю), и это, конечно же, crash dump analysis на ходу получается (т.к. со стоЯщими таймерами и убитыми таймаутами и вообще без времени, можно сказать).
В конце концов, дебаггер позволяет выловить 90% несложных багов намного быстрее, чем "вдумчивое чтение логов". Не говоря уже о том, что гигабайты логов читать (даже с супер-интеллигентными парсерами) ничуть не проще, чем тыкать step-in/step-out.

PS: да, я уже надрочился научился дебажить даже сетевые стеки, благо, MSL'и большие и эмуляция сервера с любыми таймаутами у меня тоже есть.

Здравствуйте Трололоша, Вы писали:

Т>Ну так и говори: отладчика в моих условиях нету.
Т>А то рассказываешь тут про вкус устриц тем, кто их ест постоянно.

Расскажи еще про устриц- ты меня заинтриговал.

KP>У отладчика есть один критический недостаток: лично в моем случае он доступен хорошо если в 10-20% случаев. А после того как привык оперировать логами, действительно приходишь к выводу о том, что тесты + логи покрывают 99% задач связанных с отладкой.

Удивлен, честно сказать. Что за проект? Поддержка чего-то большого и старого?
В моей практике, 90% багов — из-за невнимательности и copy-paste, и их по логам банально дольше искать.

Я хоть и согласен с постулатом "без дебаггера можно обойтись", но несложные баги (которых, опять же, всегда больше, чем сложных — прим. КО) с дебаггером найти проще, чем без.

Кстати, а что вы делаете, если есть только crash dump? Логи — сплошной mess видимо, расстреляли их память.

Здравствуйте, Трололоша, Вы писали:

Т>Здравствуйте, мыщъх, Вы писали:

Т>Отладчики разные бывают. В идеале при остановке по отладке останавливается сразу вся виртуальная машина,
Т>в которой крутится отлаживаемый софт. Но такое далеко не всегда надо, даже для системного софта.
я же говорю, что с вами все ясно.

Здравствуйте, ArtemGorikov, Вы писали:

Т>>Ну так и говори: отладчика в моих условиях нету.
Т>>А то рассказываешь тут про вкус устриц тем, кто их ест постоянно.

AG>Расскажи еще про устриц- ты меня заинтриговал.
Вкусные.
Меньше чем medium size брать нет смысла.
Что тебе ещё рассказать?

Здравствуйте, IOne1986, Вы писали:

IO>В связи с чем вопрос, куда можно податься в Москве программисту с такими навыками, что подучить?

Если Зеленоград не пугает, вакансия

Автор: Costik
Дата: 15.06.11

ещё актуальна.

Здравствуйте, мыщъх, Вы писали:

.....

М>дайте пример, когда отладчик действительно полезен и незаменим.

1) есть у нас есть процесс, в процесс загружено 100500 плагинов, в том числе сторонних и наблюдается утечка памяти;
2) если нужен анализ дедлока, креша, всех тех случаев, когда у бага есть некое устойчивое состояние;
3) если нужен анализ деградации производительности системы — иногда это проще делать инструментами;
4) если бага в большом проекте, где пересобрать всю систему — 6-8 часов, а компонент не локализован, то его нужно локализовать, логов на все случаи жизни не напасешься;
5) добавим все случаи, когда есть система, с ней нужно работать, но нет спеки. бумс, что-то не работает. вбил бряку по условию или от безысходности if (...) __asm int3, вытащил из отладчика за 5 минут все, что дампил бы двое суток.
6) когда нужно бысто проверить предположение, не пересобирая все подряд;

еще?