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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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