Как отладить тупик?

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

Есть ли другой способ, кроме просмотра дерева исходных текстов, для поиска потенциальных проблем? Есть ли способ получить доступ к стекам вызовов после того, как проблема возникла, чтобы увидеть, в чем проблема? Какие-нибудь другие инструменты / советы / приемы, которые могут помочь?


multithreading c# deadlock
person Matthew Scharley    schedule 18.07.2009    source источник

Ответы (4)


arrow_upward
10
arrow_downward

То, что вы сделали, было правильным. Если Visual Studio также заходит в тупик, это случается время от времени. Это просто невезение, если нет других проблем.

Вам не нужно запускать приложение в отладчике, чтобы отлаживать его. Запустите приложение в обычном режиме, и если возникнет тупик, вы сможете подключить VS позже. Ctrl + Alt + P, выберите процесс, выберите тип отладчика и нажмите прикрепить. Использование другого набора типов отладчика может снизить риск сбоя VS (особенно если вы не отлаживаете собственный код)

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

Если VS не работает вообще, вы всегда можете использовать windbg. Загрузите здесь: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

person chris166    schedule 18.07.2009
comment
Ссылка мертва - person Liam; 19.11.2018
comment
Если ваш тупик исчез, как только вы откроете инструменты для его поиска, вам может потребоваться изменить свою программу, чтобы помочь. Что вы можете сделать, так это запустить другой поток в вашей программе, единственная задача которого - выяснить, когда происходит взаимоблокировка, а затем выдать исключение или вызвать прерывание отладчика, чтобы ваше состояние взаимоблокировки сохранялось, чтобы вы могли его увидеть. - person Rick Velde; 08.01.2019

arrow_upward
4
arrow_downward

Я бы попробовал разные подходы в следующем порядке:

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

  • Используйте любой доступный вам инструмент для визуализации активности потоков. Я использую собственный Perl-скрипт, который анализирует журнал ОС, который мы создали, и графически отображает все переключатели контекста и показывает, когда поток прерывается.

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

Надеюсь, это поможет. Удачи!

person Community    schedule 18.07.2009

arrow_upward
0
arrow_downward

Вы можете использовать разные программы, например Intel (R) Parallel Inspector:
http://software.intel.com/en-us/intel-parallel-inspector/

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

person Mikhail Churbanov    schedule 18.07.2009
comment
Кажется, это тоже только для C / C ++ (я полагаю, неуправляемый, поскольку, насколько мне известно, управляемого C нет). - person Matthew Scharley; 18.07.2009

arrow_upward
0
arrow_downward

Как и везде, нет инструментов «серебряной пули», позволяющих выявлять все тупиковые ситуации. Все дело в последовательности, в которой разные потоки получают ресурсы, поэтому ваша задача - выяснить, где был нарушен порядок. Обычно Visual Studio или другой отладчик предоставляет трассировку стека, и вы сможете выяснить, в чем заключается несоответствие. DevPartner Studio действительно предоставляет анализ взаимоблокировок, но в прошлый раз, когда я проверил, было слишком много ложных срабатываний. Некоторые инструменты статического анализа также обнаруживают некоторые потенциальные тупиковые ситуации.

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

person Oleg Zhylin    schedule 18.07.2009