Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
Здравствуйте, Shmj, Вы писали:
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
Много лет писал без отладчика ввиду полного отсутствия оного при работе с перфокартами . Но потом, конечно, освоил отладчик.
S>Каково ваше отношение к данной идее?
Отрицательное. Дело закончится отладочной печатью, а это то же самое, но не в интерактивном режиме.
Здравствуйте, Shmj, Вы писали:
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
S>Каково ваше отношение к данной идее?
Пишу тесты, в том числе, для того, чтобы продебажить кусок кода не запуская всю огромную систему. Как тебе такое?
А вообще код коду рознь. Если нужен дебаггер, когда джейсоны гоняешь туда-сюда, то, наверное только биореактор поможет. Но индустрия — это не только это.
Здравствуйте, Shmj, Вы писали:
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
S>Каково ваше отношение к данной идее?
Здравствуйте, Shmj, Вы писали:
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик. S>Каково ваше отношение к данной идее?
Примерно такое же как к идее построения коммунизма силовыми методами. Опасная утопия.
Здравствуйте, Shmj, Вы писали:
S>Каково ваше отношение к данной идее?
Ну, про Торвальдса, например, известно, что он не использует отладчик. Я тоже по мере возможности не использую, хотя про меня это и не так широко известно.
В целом, отладчик помогает посмотреть простые вещи, но в реально сложных ситуациях загоняет человека в тупик, поощряя его искать проблему не там, где она есть, а там, где проще искать.
Но надо еще учитывать, откуда код-то взялся. Свой код я пишу с учетом того, как он будет отлаживаться. Так и код получается яснее, и работать с ним проще. А если есть 100500 килотонн легаси кода, написанного гражданами, беспомощными без отладчика, то в таком коде control flow может быть такой, что без поллитры и не разберешь.
Здравствуйте, Sharov, Вы писали:
S>В отладчике потоки можно оттормаживать, т.е. замораживать, походил одним, поставил на паузу (freeze), походил S>другим (freeze), разморозил пред. поток (thaw) и т.д. Можно понять, где race condition, где забыли поставить lock S>и т.п.
Ага, только вот этим всем начинаешь заниматься, когда уже словил ненужое переключение контекста. А когда потоки начнёшь отмораживать — не факт, что проблема воспроизведётся.
Здравствуйте, klopodav, Вы писали:
K>Иногда можно даже не удалять, а закомментировать. Хотя на первый взгляд кажется, что этот мусор засирает код. Но оказывается — такие закомментированные fprintf'ы тоже могут быть полезны как дополнение к другим комментариям. Они показывают, на что следует обратить особое внимание. И на случай, если в будущем в поведении этого кода обнаружится неведомая хрень — будет примерно понятно, что снова надо вывести в лог, чтобы эту хрень отловить.
Это называется логгирование, строчки с логгированием не комментируюся, а отключаются, на уровне компиляции или в рантайме. см. "уровни логгирования"
не-не-не, отладчиком ловить глюки многопоточности — дохлый номер, времени уйдет вагон, а пользы мало. Для этого есть другие инструменты.
Разве что под "отладчиком" понимать tracing debugger, который просто пишет все в логи, а потом эти логи можно проигрывать (replay) детерминированным образом. Но это уже не совсем отладчик (хоть и выглядит таковым), а, скорее, продвинутый log viewer. В сложных и распределенных системах, впрочем, это один из немногих работающих и удобных инструментов (жаль что мало где реализован).
Здравствуйте, Shmj, Вы писали:
S> Чистый код должен покрываться тестами
Большой вопрос, нужно ли писать эти тесты вообще! И насколько ты квалифицирован, чтобы ответственно заявлять, что после твоих тестов код 100% не содержит багов.
Одно дело — написать процедуру обновления счётчика, другое — обложить эту процедуру ТАКИМ количеством тестов, что даже бит не проскочит! Последнее требует квалификации на порядок большей, чем твоя процедурка. Уверен, что ею обладаешь??
Ну, это не говоря о том, что далеко не все вещи требуют тестов или вообще тестируемы. И последний гвозь в крышку тестов, есть ли у вас столько РЕСУРСОВ, что на 10 строк кода ты самоуверенно садишься писать 1000 строк тестов.
Здравствуйте, Baiker, Вы писали:
S>> Чистый код должен покрываться тестами B>Большой вопрос, нужно ли писать эти тесты вообще!
Я в тебе не сомневался.
B>Ну, это не говоря о том, что далеко не все вещи требуют тестов или вообще тестируемы.
Не всем, к счастью, постоянно приходится ковырять легасный гуй.
B>И последний гвозь в крышку тестов, есть ли у вас столько РЕСУРСОВ, что на 10 строк кода ты самоуверенно садишься писать 1000 строк тестов.
Строки кода не стоят ни"№я. Ценность имеет качественное решение проблемы. И тесты — немаловажная часть этого решения, ничуть не менее важная (а иногда, например в случае компиляторов, более важная) нежели покрываемый этими тестами код.
G>Не пользуюсь дебагером. Пишу логи. G>Когда ищу баг — обкладываю все вокруг fprintf'ами, которые потом удаляю.
Иногда можно даже не удалять, а закомментировать. Хотя на первый взгляд кажется, что этот мусор засирает код. Но оказывается — такие закомментированные fprintf'ы тоже могут быть полезны как дополнение к другим комментариям. Они показывают, на что следует обратить особое внимание. И на случай, если в будущем в поведении этого кода обнаружится неведомая хрень — будет примерно понятно, что снова надо вывести в лог, чтобы эту хрень отловить.
Здравствуйте, Shmj, Вы писали:
S>Каково ваше отношение к данной идее?
Когда-то очень давно, когда ёлки были зеленее, а девки красивее, научился пользоваться отладчиком, потому что никакие другие инструменты не помогали и таки пришлось разобраться в теме. До этого считал отладчик ненужной хренью. Потом часто встречал таких же молодых дебилов (ой простите, конечно же альтернативных гениев), считающих меня, умеющего пользоваться отладчиками и профайлерами, конченым маргиналом. Считающих ровно до того момента, пока возможности их инструментов не заканчивались и только отладчик мог помочь.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Вот как раз ты сейчас разглядываешь картину Айвазовского в замочную скважину убогих плюсовых отладчиков. А нормальные посоны прекрасно отлаживают целый кластер из десятков разных сервисов, совмещая это в том числе и с анализом логов, и с распределенный трейсингом.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А всевозможные пуристы с их неуместным максимализмом пусть идут в жопу, не?
Вот сам туда и иди.
Если над бракоделами не стоять с воот такой вот дубиной, то не успеешь оглянуться, как система с нормальным дизайном и адекатным покрытием юнит-тестами превращается в копромонолит с полутора хромыми тестами (остальные отключили, потому что они "падают").
Здравствуйте, Ночной Смотрящий, Вы писали:
L>>Если над бракоделами не стоять с воот такой вот дубиной, то не успеешь оглянуться, как система с нормальным дизайном и адекатным покрытием юнит-тестами превращается в копромонолит с полутора хромыми тестами (остальные отключили, потому что они "падают"). НС>И при чем тут отладчик?
Да потому вот так и норовят "небольшое изменение", для которого нужно бы написать отдельный юнит тест или исправить существующий, "по-быстренькому" "прогоняют под отладчиком".
Если вот тут сразу по рукам как следует не дать, через несколько недель будет поздно.
Здравствуйте, Shmj, Вы писали:
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
Встречал. В свое время, лет 15 назад, ныне подзабытый скандалист Луговский что-то в этом роде говорил.
Как и многое другое сейчас это юношеским максимализмом выглядит. Лезть в отладчик — это не признак грязного кода, а когда не совсем понятно, что вообще происходит.
Здравствуйте, Shmj, Вы писали:
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик. S>Каково ваше отношение к данной идее?
С одной стороны, глупо отказываться от полезного инструмента по религиозным соображениям. С другой, чем опытнее программист, тем меньше времени он проводит в отладчике, т.к. посмотреть на визуально понятный код, покрытый тестами, намного проще, чем воспроизводить баг и ставить брейкпоинты.
С третьей, с этой идеей носятся пользователи языков программирования и сред, где нормального отладчика просто нет. Им проще отрицать полезность отладчика, чем признать ущербность любимой технологии.
Здравствуйте, Pzz, Вы писали:
Pzz>в реально сложных ситуациях загоняет человека в тупик, поощряя его искать проблему не там, где она есть, а там, где проще искать.
Когда человек не умеет использовать отладчик то да, бывает.
B>Большой вопрос, нужно ли писать эти тесты вообще!
Полезно. На всякое изменение кода иметь возможность 1 нажатием проверить "вообще всё", что когда-либо умели проверять. >И насколько ты квалифицирован, чтобы ответственно заявлять, что после твоих тестов код 100% не содержит багов.
Сказать "успешно исполняет типовые сценарии" — уже весьма немало. B>Одно дело — написать процедуру обновления счётчика, другое — обложить эту процедуру ТАКИМ количеством тестов, что даже бит не проскочит! Последнее требует квалификации на порядок большей, чем твоя процедурка. Уверен, что ею обладаешь??
Статусные игры какие-то. Тестировать надо не код, а решаемые задачи. Чтобы сдача заказчику приближалась и рекламации уменьшались, а не чтобы всяким оценщикам квалификации было где нос подточить.
Здравствуйте, Shmj, Вы писали:
S>Встречались ли вы с идеей, что дебаггер использовать не стоит
Не пользуюсь дебагером. Пишу логи.
Когда ищу баг — обкладываю все вокруг fprintf'ами, которые потом удаляю.
S>Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
Юнит-тесты вещь безусловно хорошая.
Но на все случаи — ненужный оверхед.
Здравствуйте, Shmj, Вы писали:
S>Каково ваше отношение к данной идее?
Любую хорошую идею можно довести до абсурда.
Тебе так некоторые скажут, например, что TDD, где тесты не пишутся до кода — это и не TDD вовсе.
Что комментарии не нужны, т.к. хороший код — самодокументируемый.
Что код не только отлаживать не нужно, но и профилировать тоже, ибо "хороший код всегда написан максимально эффективно".
Далее можно прийти к тому, что код и запускать для проверки не обязательно, т.к. "этот код идеален и не содержит ошибок"
И т.п.
Здравствуйте, Sharov, Вы писали:
S>достижимо да и сложно, т.е. нужно быть крутым спецом в этом деле. Далее, как без отладчика находить и воспроизводить баг в многопоточной программе?
В многопоточной? А разве в этом случае как раз не проще писать в логи? В отладчике будет прыгать между потоками.
Здравствуйте, Shmj, Вы писали:
S>>достижимо да и сложно, т.е. нужно быть крутым спецом в этом деле. Далее, как без отладчика находить и воспроизводить баг в многопоточной программе? S>В многопоточной? А разве в этом случае как раз не проще писать в логи? В отладчике будет прыгать между потоками.
В отладчике потоки можно оттормаживать, т.е. замораживать, походил одним, поставил на паузу (freeze), походил
другим (freeze), разморозил пред. поток (thaw) и т.д. Можно понять, где race condition, где забыли поставить lock
и т.п.
Здравствуйте, Shmj, Вы писали:
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
S>Каково ваше отношение к данной идее?
Если у тебя достаточно большая программа не фурычит — хрен ты её отладчиком отладишь.
Это то же самое, что картину какого-нибудь Айвазовского в замочную скважину разглядывать.
Программа должна САМА каким-то образом сказать, что в ней не в порядке.
Желательно в графическом виде.
Здравствуйте, CreatorCray, Вы писали:
CC>Это зависит от того, что в ней не фурычит. CC>Отладчик это как раз микроскоп, когда уже огородили до загончика и надо понять что там происходит на субатомнов уровне
Воот. Отладчик — это тонкий инструмент. И использовать его нужно по назначению, а не как кувалду для забивания костылей в шпалы, как в подветке про многопоточность.
S>Воспроизводить, а не ловить. Банально быстрее посмотреть, что два потока работают непотокобезопасно с разделяемыми данными,
Это слишком сложно (порой и невозможно) посмотреть в дебаггере на живом (реальном) коде, потому что там все равно есть недетерминизм (os scheduling иначе сработает, или таймер не в ту микросекунду тикнет). Поэтому "дебажат" не в реалтайме, и не саму программу, а трейсы.
И вообще для многопоточности и распределенных систем лучше пользоваться другим инструментарием. В первую очередь моделированием и model checking.
Здравствуйте, Sharov, Вы писали:
S>Я говорил про свой, относительно простой, опыт на платформе .net с отладчиком vs. Когда мне прилетел с прода странное
Соглашусь со SkyDance.
Если подобный код в принципе попадает в прод, то... ну плохи дела, в общем.
Проблемы многопоточности всегда лежат в плоскости логики/архитектуры (ну и исчезающе мало приходится на какую-нибудь забавную эзотерику вроде вроде "мы забыли volatile, а компилятор и правда оптимизировал все в ноль").
Как правило, попытки "починить" кривой многопоточный код с помощью отладчика заканчивается втыканием мьютексов куда попало со всеми радостями вроде дедлоков (но реже) и переносом бага в другое место. Или превращением программы в однопоточную, т.к. все потоки все время ждут одного.
Здравствуйте, Shmj, Вы писали:
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
Здравствуйте, bnk, Вы писали:
bnk>Примерно такое же как к идее построения коммунизма силовыми методами. Опасная утопия.
Скорее как к выковыриванию крестовых шурупов плоской отвёрткой, потому как крестовую отвёртку запрещено трогать по религиозным причинам
Здравствуйте, Shmj, Вы писали:
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
S>Каково ваше отношение к данной идее?
Ревершу в качестве хобби прошивки машин. Хз, как тут без дебаггинга обойтись? Прошивка работает, понять некоторые вещи можно только по логированию памяти. Вот и приходится дебажить через логи и перепрошивку.
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик. S>Каково ваше отношение к данной идее?
Уважаемые сеньоры проектируют всё сразу правильно в визио, им даже студию запускать не надо.
Более-менее способному мыдлу остаётся всего лишь внимательно закодить как велели и покрыть всё юнитами теста (не запуская всё в сборе и на реальных данных).
А кому достанется исправлять баги, отладчиком приводить полученное изделие в работающее состояние на продакшене, "ковыряться руками в земле" — тот низкоранговый и его дОлжно гнобить и унижать.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну, про Торвальдса, например, известно, что он не использует отладчик.
И? Он ещё и плюсы не осилил, и что?
Pzz>В целом, отладчик помогает посмотреть простые вещи, но в реально сложных ситуациях загоняет человека в тупик
С чего бы?
Pzz> поощряя его искать проблему не там, где она есть, а там, где проще искать.
Это чушь.
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
S>Каково ваше отношение к данной идее?
Хотя никаких предубеждений против дебаггера не имею — тем не менее непосредственно дебаггером пользуюсь редко. Конечно, тесты это не панацея, да и далеко не всегда я стремлюсь к полному покрытию тестами. Но зато для отладки часто использую запись в логи — зачастую это оказывается удобнее, чем прыгать по брекпойнтам или создавать хитровывернутые условные брекпойнты.
А вот при работе с веб-фронтендом (что хоть и несколько не мое, но иногда заниматься приходится) — нередко пользуюсь инструментарием Web Developer Tools (пусть это и не совсем дебаггер, но близкий по смыслу инструмент). Потому что без его возможностей там часто бывает так, что черт ногу сломит.
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
Не только встречались, но и сам работаю практически без отладчика.
Отладчик мне требуется только в двух слукчаях:
1. Пройти по чужому незнакомому коду, посмотреть что за чем и когда следует. На новой работе вот как раз пришлось полазить java-коде.
2. Сложный баг, который "руками" не обнаруживается. Это бывает очень редко.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, graniar, Вы писали:
G>>Не пользуюсь дебагером. Пишу логи. G>>Когда ищу баг — обкладываю все вокруг fprintf'ами, которые потом удаляю.
S>А в чем профит?
Не сильно вмешиваешься в ход выполнения кода. Код может быть многопоточным, могут быть таймауты и всё такое.
Например:
Брейкпоинт останавливает весь мир.
А при следующем степ-овер ты, внезапно, оказываешся в другом потоке где-то в catch на обработке ошибки, что какая-то операция отвалилась по таймауту.
Здравствуйте, Shmj, Вы писали:
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
Тут топики на тему приключаются регулярно.
S>Каково ваше отношение к данной идее?
Здравствуйте, klopodav, Вы писали:
K>Иногда можно даже не удалять, а закомментировать.
Какие-то оставляю закомментированными подольше.
Но если, к примеру ищу где сегфолтится, тупо бинарным поиском ищу. Обкладываю чуть не через строчку, а потом подчищаю.
И всегда без отступов, чтоб удобнее удалять и не перепутать, типа такого:
K> И на случай, если в будущем в поведении этого кода обнаружится неведомая хрень — будет примерно понятно, что снова надо вывести в лог, чтобы эту хрень отловить.
В целом, идея хорошая, т.е. писать (юнит)тесты так, чтобы необходимость в отладчике отпадала. На практиче это едва ли
достижимо да и сложно, т.е. нужно быть крутым спецом в этом деле. Далее, как без отладчика находить и воспроизводить баг в многопоточной программе?
Или отладка взаимодействия с каким-нибудь переферийным устройством типа драйвера и т.п.
Здравствуйте, Doom100500, Вы писали:
S>>В отладчике потоки можно оттормаживать, т.е. замораживать, походил одним, поставил на паузу (freeze), походил S>>другим (freeze), разморозил пред. поток (thaw) и т.д. Можно понять, где race condition, где забыли поставить lock S>>и т.п. D>Ага, только вот этим всем начинаешь заниматься, когда уже словил ненужое переключение контекста. А когда потоки начнёшь отмораживать — не факт, что проблема воспроизведётся.
При чем здесь контекст и разделяемые данные, с возможным rc? Т.е. у потоков контекст общий, если мы не говорим
про .net'овский контекст синхронизации.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Doom100500, Вы писали:
S>>>В отладчике потоки можно оттормаживать, т.е. замораживать, походил одним, поставил на паузу (freeze), походил S>>>другим (freeze), разморозил пред. поток (thaw) и т.д. Можно понять, где race condition, где забыли поставить lock S>>>и т.п. D>>Ага, только вот этим всем начинаешь заниматься, когда уже словил ненужое переключение контекста. А когда потоки начнёшь отмораживать — не факт, что проблема воспроизведётся.
S>При чем здесь контекст и разделяемые данные, с возможным rc? Т.е. у потоков контекст общий, если мы не говорим S>про .net'овский контекст синхронизации.
Я говорил о switch context, который имел место, когда многопоточность бежала на одном ядре. Тогда процессор должен сохранить и загрузить регистры. Сейчас это тоже происходит, когда потоков больше, чем ядер.
Я не корректно употребил этот термин — имел в виду состояние, когда после шага в отладчике, оказываешься в стеке (контексте) другого потока (из-за исключения, например, MyCustomTimeoutException).
А посыл был про то, что только после этого, обычно вспоминают, что можно потоки замораживать и размораживать, а это значит, что начинают отладку заново, а тут уже и проблема может не воспроизвестись, и фриз других потоков может повлиять на результат. А логи бы рассказали намного больше.
Здравствуйте, Doom100500, Вы писали:
S>>При чем здесь контекст и разделяемые данные, с возможным rc? Т.е. у потоков контекст общий, если мы не говорим S>>про .net'овский контекст синхронизации. D>Я говорил о switch context, который имел место, когда многопоточность бежала на одном ядре. Тогда процессор должен сохранить и загрузить регистры. Сейчас это тоже происходит, когда потоков больше, чем ядер.
Я это понял, но контекст актуален для процесса, у потоков он общий. Поэтому не вижу проблемы.
D>Я не корректно употребил этот термин — имел в виду состояние, когда после шага в отладчике, оказываешься в стеке (контексте) другого потока (из-за исключения, например, MyCustomTimeoutException).
И что, как это влияет на контекс процесса и на расшаренные данные? Тут ничего не должно поменяться. Речь о потоках в рамках единого
процесса. Кстати, а как такое возможно, если после исключения в активном потоке я оказался в др. потоке?
Как делал я, ловил все потоки на соотв. точке прерывания, отмараживал все и потом размаривал по одно и ходил по коду,
поочередно размораживая\замораживая другие.
D>А посыл был про то, что только после этого, обычно вспоминают, что можно потоки замораживать и размораживать, а это значит, что начинают отладку заново, а тут уже и проблема может не воспроизвестись, и фриз других потоков может повлиять на результат. А логи бы рассказали намного больше.
Я ни разу не отменяю логи. Проблем с многопоточностью из-за переключений контекста процесса у меня не было, все
в рамках одного процесса. Что-то такое может быть при отладке на уровне ядра, но я говорил про контекст .net и соотв.
управляемых потоках.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Doom100500, Вы писали:
S>>>При чем здесь контекст и разделяемые данные, с возможным rc? Т.е. у потоков контекст общий, если мы не говорим S>>>про .net'овский контекст синхронизации. D>>Я говорил о switch context, который имел место, когда многопоточность бежала на одном ядре. Тогда процессор должен сохранить и загрузить регистры. Сейчас это тоже происходит, когда потоков больше, чем ядер.
S>Я это понял, но контекст актуален для процесса, у потоков он общий. Поэтому не вижу проблемы.
Нет, не общий. У каждого потока свой стэк (регистр процессора), и поток мог быть прерван планировщиком между любыми не атомарными опрациями (регистры данных, MMX, SSE, etc). Это и какие-либо другие данные (нужные планировщику) и являются контекстом любого потока в системе — без разницы в одном они процессе или в разных. Переключение этого контекста происходит, если потоков больше, чем ядер, и планировщику надо давать процессорное время вытесняя другой поток. Планировщик вообще не оперирует процессами, а только потоками.
D>>Я не корректно употребил этот термин — имел в виду состояние, когда после шага в отладчике, оказываешься в стеке (контексте) другого потока (из-за исключения, например, MyCustomTimeoutException).
S>И что, как это влияет на контекс процесса и на расшаренные данные? Тут ничего не должно поменяться. Речь о потоках в рамках единого процесса.
Один поток может поменять четверть байтов в какой-то переменной типа ULONGLONG, а другой читает оттуда. Даже в рамках одного процесса эта переменная может быть на чертверь обновлена и прочитана. Это одинаково, независимо от того принадлежат ли потоки одному процессу или нет.
S>Кстати, а как такое возможно, если после исключения в активном потоке я оказался в др. потоке?
Нет, не так:
— Отлаживаем наш основной поток, в котором хотим воспроизвести проблему.
— Где-то выше по сценарию система запустила поток, который запустил операцию и ждёт её заверешения.
— Мы умные, и бесконечных ожиданий у нас нет. Вместо этого есть таймаут.
— Мы тупим в отладчике нак строкой 2990 и сморим на наши разделяемые и не разделяемые данные — изучаем их, возможно, сравниваем с какими-то эталонными или хз.
— Решаем сделать шаг и останавливаемся на исключении MyCustomTimeoutException в том потоке, который запустил операцию и ждёт её заверешения. А остановились мы там, потому что, наученные другим горьким оытом, мы выставили в отладчике опцию останавливаться на исключениях.
— Мы поняли, что тот поток, который выкинул тот самый MyCustomTimeoutException, уже успел похерить все данные, на которые мы так пристально смортрели. И начинаем отладочную сессию заново.
— Мы фризим потоки, и проблема не воспроизводится.
S>Как делал я, ловил все потоки на соотв. точке прерывания, отмараживал все и потом размаривал по одно и ходил по коду, S>поочередно размораживая\замораживая другие.
Я так тоже делал, когда логи показали где именно проблема и нужно было уже уточнить нюансы.
D>>А посыл был про то, что только после этого, обычно вспоминают, что можно потоки замораживать и размораживать, а это значит, что начинают отладку заново, а тут уже и проблема может не воспроизвестись, и фриз других потоков может повлиять на результат. А логи бы рассказали намного больше.
S>Я ни разу не отменяю логи. Проблем с многопоточностью из-за переключений контекста процесса у меня не было, все S>в рамках одного процесса. Что-то такое может быть при отладке на уровне ядра, но я говорил про контекст .net и соотв. S>управляемых потоках.
Все, даже управляемые потоки, управляются планировщиком ОС.
И я вообще не отменяю отладчик. Но он хорош, когда проблему уже отделил от основной логики и уверен, что нет никаких других стронних эффектов.
Здравствуйте, alpha21264, Вы писали:
A>Если у тебя достаточно большая программа не фурычит — хрен ты её отладчиком отладишь.
Это зависит от того, что в ней не фурычит.
Отладчик это как раз микроскоп, когда уже огородили до загончика и надо понять что там происходит на субатомнов уровне
Здравствуйте, alpha21264, Вы писали:
A>Если у тебя достаточно большая программа не фурычит — хрен ты её отладчиком отладишь. A>Это то же самое, что картину какого-нибудь Айвазовского в замочную скважину разглядывать.
Вот как раз ты сейчас разглядываешь картину Айвазовского в замочную скважину убогих плюсовых отладчиков. А нормальные посоны прекрасно отлаживают целый кластер из десятков разных сервисов, совмещая это в том числе и с анализом логов, и с распределенный трейсингом.
A>Программа должна САМА каким-то образом сказать, что в ней не в порядке. A>Желательно в графическом виде.
Здравствуйте, CreatorCray, Вы писали:
CC>Отладчик это как раз микроскоп, когда уже огородили до загончика и надо понять что там происходит на субатомнов уровне
Иногда отладчик и загончик тоже помогает огородить. Не будешь же ты вообще все состояние вываливать в логи, верно?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Вот как раз ты сейчас разглядываешь картину Айвазовского в замочную скважину убогих плюсовых отладчиков. А нормальные посоны прекрасно отлаживают целый кластер из десятков разных сервисов, совмещая это в том числе и с анализом логов, и с распределенный трейсингом.
Это как бы разные вещи. Логгирование и трейсер позволят найти проблемный микросервис, а также правильный запрос и неправильный ответ к нему. Дальше-то что? Не все баги фиксятся методом внимательно взгляда в код, бывают сложные кодовые базы.
Здравствуйте, scf, Вы писали:
scf>Это как бы разные вещи.
Разные. В этом и прелесть использования разных механизмов параллельно. Что то в одном видно, что то в другом.
scf> Логгирование и трейсер позволят найти проблемный микросервис,
Не только. И отладчик тоже, бывает, помогает найти проблемный сервис — логи это не дамп процесса, инфа там в любом случае неполная, особенно если сервис не твой.
Я вообще не понимаю попытку некоторых в этом топике максимально сузить облать применения тех или иных инструментов. Очевидно что их надо применять строго везде, где от них есть какая то польза. А всевозможные пуристы с их неуместным максимализмом пусть идут в жопу, не?
Здравствуйте, landerhigh, Вы писали:
L>Если над бракоделами не стоять с воот такой вот дубиной, то не успеешь оглянуться, как система с нормальным дизайном и адекатным покрытием юнит-тестами превращается в копромонолит с полутора хромыми тестами (остальные отключили, потому что они "падают").
Здравствуйте, landerhigh, Вы писали:
НС>>И при чем тут отладчик? L>Да потому вот так и норовят "небольшое изменение", для которого нужно бы написать отдельный юнит тест или исправить существующий, "по-быстренькому" "прогоняют под отладчиком".
Ни разу с таким не сталкивался и не очень понимаю как такое возможно. Решение о написании теста на тот или иной кейс никак не зависит от наличия отладчика.
Здравствуйте, Ночной Смотрящий, Вы писали:
L>>Да потому вот так и норовят "небольшое изменение", для которого нужно бы написать отдельный юнит тест или исправить существующий, "по-быстренькому" "прогоняют под отладчиком". НС>Ни разу с таким не сталкивался и не очень понимаю как такое возможно. Решение о написании теста на тот или иной кейс никак не зависит от наличия отладчика.
Здравствуйте, Doom100500, Вы писали:
S>>И что, как это влияет на контекс процесса и на расшаренные данные? Тут ничего не должно поменяться. Речь о потоках в рамках единого процесса. D>Один поток может поменять четверть байтов в какой-то переменной типа ULONGLONG, а другой читает оттуда. Даже в рамках одного процесса эта переменная может быть на чертверь обновлена и прочитана. Это одинаково, независимо от того принадлежат ли потоки одному процессу или нет.
Все так, если операция не атомарна (чтение\запись адреса в памяти или CAS какой-нибудь). Но можно ставить bp в соотв.
место, а лучше до и отлавливать и тормозить другие потоки. В отладке не проблеме это избежать, надо только аккуратно
ходить отлаживаемым потоком и следить, чтобы не перекинуло на другой. Я отлавливал все левые потоки на br и замораживал.
S>>Кстати, а как такое возможно, если после исключения в активном потоке я оказался в др. потоке? D>Нет, не так: D>- Отлаживаем наш основной поток, в котором хотим воспроизвести проблему. D>- Где-то выше по сценарию система запустила поток, который запустил операцию и ждёт её заверешения. D>- Мы умные, и бесконечных ожиданий у нас нет. Вместо этого есть таймаут. D>- Мы тупим в отладчике нак строкой 2990 и сморим на наши разделяемые и не разделяемые данные — изучаем их, возможно, сравниваем с какими-то эталонными или хз. D>- Решаем сделать шаг и останавливаемся на исключении MyCustomTimeoutException в том потоке, который запустил операцию и ждёт её заверешения. А остановились мы там, потому что, наученные другим горьким оытом, мы выставили в отладчике опцию останавливаться на исключениях. D>- Мы поняли, что тот поток, который выкинул тот самый MyCustomTimeoutException, уже успел похерить все данные, на которые мы так пристально смортрели. И начинаем отладочную сессию заново. D>- Мы фризим потоки, и проблема не воспроизводится.
Понял о чем речь. Выше я это отметил -- можно ставить bp в callback'е. А можно просто аккуратно ходить своим потоком и не долбить F9-F10,
и внимательно следить какой поток активный, чтобы потом переключиться на нужный. Т.е. поток по таймауту надо отловить до того, как он
упадет с MyCustomTimeoutException. Ну либо вручную под отладчиком увеличить таймаут или вообще -1 сделать.
Здравствуйте, SkyDance, Вы писали:
S>>В отладчике потоки можно оттормаживать SD>не-не-не, отладчиком ловить глюки многопоточности — дохлый номер, времени уйдет вагон, а пользы мало. Для этого есть другие инструменты.
Воспроизводить, а не ловить. Банально быстрее посмотреть, что два потока работают непотокобезопасно с разделяемыми данными,
чем вчитываться в код, котороый еще может быть и легаси и т.п.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, SkyDance, Вы писали:
S>>>В отладчике потоки можно оттормаживать SD>>не-не-не, отладчиком ловить глюки многопоточности — дохлый номер, времени уйдет вагон, а пользы мало. Для этого есть другие инструменты.
S>Воспроизводить, а не ловить. Банально быстрее посмотреть, что два потока работают непотокобезопасно с разделяемыми данными, S>чем вчитываться в код, котороый еще может быть и легаси и т.п.
Т.е. именно, когда ошибку локализовал, и сейчас уже с пинцетом (отладчиком) разбираешся в нюансах (тупо чинишь уже, грубо говоря).
Но чтобы локализовать эту ошибку (не воспроизвести, а именно локализовать) в многопоточном окружении, отладчик только помешает.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Иногда отладчик и загончик тоже помогает огородить. Не будешь же ты вообще все состояние вываливать в логи, верно?
"Случаи, корнет, разные бывают-с" (С)
В любом случае инструмент выбирается под задачу. И лучше когда есть возможность выбора из разных инструментов, чем только один.
Здравствуйте, CreatorCray, Вы писали:
L>>Воот. Отладчик — это тонкий инструмент. И использовать его нужно по назначению CC>А что, с этим кто то спорит?
Так хотя бы в соседней подветке про гнездо багов в многопоточной программе.
Здравствуйте, SkyDance, Вы писали:
SD>Это слишком сложно (порой и невозможно) посмотреть в дебаггере на живом (реальном) коде, потому что там все равно есть недетерминизм (os scheduling иначе сработает, или таймер не в ту микросекунду тикнет). Поэтому "дебажат" не в реалтайме, и не саму программу, а трейсы.
Я говорил про свой, относительно простой, опыт на платформе .net с отладчиком vs. Когда мне прилетел с прода странное
исключение из-за проблем добавления эл-та в коллекцию, которого при однопоточном варианте быть не должно. Взял отладчик,
походил потоками, довел до ситуации, когда несколько потоков работают без синхронизации с непотокобез. структурой данных.
Race condition? Race condition. Проблема найдена, добавил соотв. синхронизацию. Можно было вчитывать в логику, кот. и так
не тривиальна, а еще держать в уме, что параллельно работает несколько других потоков. А можно просто взять отладчик и за\
10-15 минут потвердить свои догадки и решить проблему.
SD>И вообще для многопоточности и распределенных систем лучше пользоваться другим инструментарием. В первую очередь моделированием и model checking.
А ну а если их нету? И я вовсе на настаиваю на отладчике как сереберяной пуле. Просто в моем случае он был мне полезен, что
никак не отменяет др. подходов и инструментов.
S>Взял отладчик, S>походил потоками, довел до ситуации, когда несколько потоков работают без синхронизации с непотокобез. структурой данных.
Такое обычно достижимо только для совсем тривиальных случаев, которые видно в коде, если его внимательно прочитать (eagle's eye debugging).
S>А ну а если их нету?
Да даже если есть, первым делом нужно написать тест, который будет воспроизводить проблему. Потому что если баг будет пофикшен без добавления теста, можно дать гарантию, что он появится снова на следующей итерации разработки продукта.
Лично для меня дебаггер является удобным способом смотреть логику работы совсем уж незнакомой программы (с помощью step into обнаруживать всякую магию вроде спрятанных вызовов, двойной диспетчеризации и т.п.).
Здравствуйте, Shmj, Вы писали:
S>Встречались ли вы с идеей, что дебаггер использовать не стоит — что если рука тянется к оному — это признак грязного кода? Чистый код должен покрываться тестами и нет необходимости лезть в отладчик.
S>Каково ваше отношение к данной идее?
Мне о том, что программировать надо без отладчика всегда рассказывали фанаты редактора vim, когда я интересовался когда же там наконец-то появится нормальная интеграция с отладчиком.
Отладчиком пользоваться можно и нужно. Это полезный инструмент, который реально помогает разобраться в коде, и экономит время.
С другой стороны, надо понимать, что отладчик далеко не везде может помочь, он может оказаться бесполезен или даже вреден. Поэтому умение дебажить прогу без отладчика довольно полезно, ну и вообще привычка немного подумать прежде чем запускать отладчик, тоже довольно полезна.
L>Если подобный код в принципе попадает в прод, то... ну плохи дела, в общем. L>Проблемы многопоточности всегда лежат в плоскости логики/архитектуры (ну и исчезающе мало приходится на какую-нибудь забавную
Ой, ладно. В реальности был написан код, который был рассчитан на 1 поток. В целях ускорения произв-ти я добавил
многопоточность, долгим и внимательным чтением кода нашел все места, где надо добавить синхронизацию, но оказалось, что
что-то продолбал. Жизненная ситуация, переписывать код -- не вариант.
L> эзотерику вроде вроде "мы забыли volatile, а компилятор и правда оптимизировал все в ноль").
volatile, к слову, вообще не про это. В шарпе, как минимум.
L>Как правило, попытки "починить" кривой многопоточный код с помощью отладчика заканчивается втыканием мьютексов куда попало со всеми радостями вроде дедлоков (но реже) и переносом бага в другое место. Или превращением программы в однопоточную, т.к. все потоки все время ждут одного.
Я не говорил починить, я говорил, что взял в руки отладчик и воспроизвел проблему, кот. в однопоточном коде
скорее всего в принципе быть не должно -- добавление-удаление эл-та в коллекцию. А чтобы не было дедлоков, надо
внимательно читать код или знать его хорошо.
Еще раз -- прилетает ошибка, которая в однопоточном коде практически не реальна (см. выше),
остается проверить многопоточный сценарий -- запустил тест, походил потоками под отлдакой и добился возникновения проблемы,
т.е. race condition. Все, подтвердил свои догадки. В чем тут проблема?
. Но потом, конечно, освоил отладчик.
Если нам не помогут, то мы тоже никого не пощадим.
