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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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