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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

-Используйте любой инструмент, который вы можете получить, чтобы визуализировать активность потока, я использую встроенный perl script, который анализирует журнал OS, который мы сделали, и графически отображает все переключатели контекста и показывает, когда поток получает pre-empted,

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

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

Ответ 3

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

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

Ответ 4

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

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