Всем, привет.

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

Поведение Студии (.net) просто раздражает. Может быть я не знаю как ее готовить, но у меня при нажатии на F10/F11 (Step over/Step into) происходит хаотическое переключение потоков и управление оказывается на на следующей строчке, а черт знает где. В таких условиях пользоваться отладчиком становится невозможно.

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

Так же интересует как обстоят дела в других IDE/отладчиках.

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

VD>Предлагаю поделиться своими мыслями про отладку многопоточных приложений (к которым, скоро, будут относиться большинство приложений).

Логи + пристальное изучение исходных кодов + тесты. Прыжки под отладчиком в многопоточном коде неизбежны, так как в этом заключена вся суть многопоточного кода. Кроме того, особого смысла в прохождении в хождении по многопоточному коду под отладчиком нет, т.к. гонки, дедлоки и другие особенности многопоточных приложений просто не будут вылезать.

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

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

KP>Логи + пристальное изучение исходных кодов + тесты.

Я же просил про логи не рассказывать. Логи — это экстенсивны путь. Чтение исходников это вообще смешно. Это точно не отладка.

Меня интересуют приемы и знания.

Что касается "гонок", то в коде не только они бывают. Я тут два дня искал примитивную ошибку последовательности вычислений не связанную с гонками и дедлоками. Если бы отладчик просто дал бы пройти по одному из потоков по шагам, я бы ее нашел за 10 минут. Но эти прыжки — это просто издевательство. Не верю, что нельзя изолировать поток и идти только по нему.

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

Я ничего лучше чем использовать окошко Threads и вручную каждому, или группе,
потоков проставлять Freeze or Thaw не знаю.

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

VD>Меня интересуют приемы и знания.

VD>Я тут два дня иска примитивную ошибку последовательности вычислений не связанную с гонками и дедлоками. Если бы отладчик просто дал бы пройти по одному из потоков по шагам, я бы ее нашел за 10 минут. Но эти прыжки — это просто издевательство. Не верю, что нельзя изолировать поток и идти только по нему.

Почему в таком случае просто в отладчике не сделать suspend всем потокам кроме того что интересует?

VD>Предлагаю поделиться своими мыслями про отладку многопоточных приложений (к которым, скоро, будут относиться большинство приложений).

Вообще-то от чисто многопоточных приложений вроде парадигма сдвигается в сторону обмена сообщениями через async/await где традиционные примитивы синхронизации нужны уже гораздо реже, изоляция между задачами должна быть лучше, а степень параллелизации вообще устанавливается Scheduler'ом, и в отладочном окружение можеть быть ограничена одним потоком, соответственно без всех этих прыжков с потока на поток.

Но в процессе реализации красивой идеи как-то так получилось что отладка множества Task'ов ещё хуже чем отладка множества потоков

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

S>Я ничего лучше чем использовать окошко Threads и вручную каждому, или группе,
S>потоков проставлять Freeze or Thaw не знаю.

Там можно заморозить конкурирующие потоки и поглядеть, что происходит в оставшихся?

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

AJD>Почему в таком случае просто в отладчике не сделать suspend всем потокам кроме того что интересует?

Например, потому что не знаешь о наличии такой возможности.

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


VD>Там можно заморозить конкурирующие потоки и поглядеть, что происходит в оставшихся?

Угу.

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

_>Вообще-то от чисто многопоточных приложений вроде парадигма сдвигается в сторону обмена сообщениями через async/await где традиционные примитивы синхронизации нужны уже гораздо реже, изоляция между задачами должна быть лучше, а степень параллелизации вообще устанавливается Scheduler'ом, и в отладочном окружение можеть быть ограничена одним потоком, соответственно без всех этих прыжков с потока на поток.

Ага. У нас примерно так и есть. Изоляция довольно хорошая. За счет неизменяемости и т.п. Но, проблема в том, что Студии это объяснить очень не просто. Ей не в домек, что ходлить по нескольким потокам одновременно — глупо.

Тут вот посоветовали замораживать другие потоки. Не знал что это можно. Попробую в будущем.

_>Но в процессе реализации красивой идеи как-то так получилось что отладка множества Task'ов ещё хуже чем отладка множества потоков

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

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

S>Угу.

Вот что-то подобное я и искал. В отладчике есть еще какие-то флаги. Но это явно какая-то фигня не относящаяся к делу.

ЗЫ

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

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

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

S>>Угу.

VD>Вот что-то подобное я и искал. В отладчике есть еще какие-то флаги. Но это явно какая-то фигня не относящаяся к делу.

Начиная с vs2010 есть еще дополнительные окошки для работы с тасками.

VD>ЗЫ

VD>Вообще странно, что отладчик не дает идти по одному потомку параллельно исполняя и другие (квантами). Это было бы наиболее логично.

А как Вы себе это представляете? Интерфейс какой?

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

AJD>>Почему в таком случае просто в отладчике не сделать suspend всем потокам кроме того что интересует?

VD>Например, потому что не знаешь о наличии такой возможности.

такая возможность есть в самой ОС, даже если бы этого не было в отладчике — это можно было бы сделать внешней утилитой типа ProcessExplorer'а

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

VD>Всем, привет.

VD>Предлагаю поделиться своими мыслями про отладку многопоточных приложений (к которым, скоро, будут относиться большинство приложений).

VD>Поведение Студии (.net) просто раздражает. Может быть я не знаю как ее готовить, но у меня при нажатии на F10/F11 (Step over/Step into) происходит хаотическое переключение потоков и управление оказывается на на следующей строчке, а черт знает где. В таких условиях пользоваться отладчиком становится невозможно.

Не делайте Step в каждом потоке и не будете прыгать между ними, после срабатывания нужного бряка — убирайте его или задизаблите, чтобы другой поток на нем не брякнулся. Ну а если выкинуло в другой поток нажмите в нем Continue и больше отладчик в нем не остановиться (если конечно опять на какой либо бряк не споткнётся) .

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


VD>Предлагаю поделиться своими мыслями про отладку многопоточных приложений (к которым, скоро, будут относиться большинство приложений).

Если достаточно только текущего потока, то должно помочь Debug Single Thread extension.
Для vs2010 точно работает, насчёт следующих версий студии не уверен. Если само не поставится, нужно будет поправить манифест.

Для сложных случаев — выставить just my code flag для нужных потоков в threads window.

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


VD>Если честно, не вижу разницы. Просто странно, что в 2014 году многопоточная отладка поддерживается отладчиком на уровне плинтуса.

На своей работе расскажи, пусть напишут ReDebugger для студии...

Здравствуйте, Аноним, Вы писали:

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


VD>>Если честно, не вижу разницы. Просто странно, что в 2014 году многопоточная отладка поддерживается отладчиком на уровне плинтуса.

А>На своей работе расскажи, пусть напишут ReDebugger для студии...

Потому, что https://www.google.com/search?hl=en&q=VisualStudio+multithreaded+debugging

Там вторая ссылка — http://msdn.microsoft.com/en-us/library/bb157784.aspx

И зачем два дня страдать?

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


A>такая возможность есть в самой ОС, даже если бы этого не было в отладчике — это можно было бы сделать внешней утилитой типа ProcessExplorer'а

очень удобно... И как маппировать native потоки на managed?

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

VD>Всем, привет.

VD>Предлагаю поделиться своими мыслями про отладку многопоточных приложений (к которым, скоро, будут относиться большинство приложений).

еще одна техника непостоянных/временных логов — преобразовывать брейкпойнты в трейспойнты. Но лучше все таки продуманная сеть постоянных =)

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

VD>у меня при нажатии на F10/F11 (Step over/Step into) происходит хаотическое переключение потоков и управление оказывается на на следующей строчке, а черт знает где. В таких условиях пользоваться отладчиком становится невозможно.
находясь в другом потоке, следует нажать на F5 (run) и дебаггер вернется на старый поток и след инструкцию (для C++ работает)
морозить все потоки, кроме интересующего, просто неудобно (много кликов надо сделать). я бы предложил добавить новые кнопки: step into current thread only, step out current thread only или одной кнопкой замораживать\размораживать все потоки, кроме текущего
хз, может, уже и есть такие возможности