Диагностика взаимоблокировок в программе Win32

Question

Каковы шаги и методы устранения очевидного зависания из-за тупиковой ситуации в производственном процессе Win32.Я слышал, что для этой цели можно использовать WinDbg, но не могли бы вы дать четкие подсказки, как это можно сделать?

Answer 1

Этот почта должен помочь вам начать работу с различными вариантами. Проверьте сообщения с тегами «Отладка».

Еще одна полезная статья о отладка взаимоблокировок..

Answer 2

Отладка настоящей тупиковой ситуации на самом деле довольно проста, если у вас есть доступ к исходному коду и дампу памяти (или сеансу отладки в реальном времени).

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

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

Answer 3

Если вам очень лень, вы можете установить Application Verifier, затем добавить свой модуль и выбрать из базового теста только «блокировки».тогда вы сможете запустить свое приложение под любым отладчиком.
Если произойдет взаимоблокировка критического раздела, вы сразу же найдете причину.

Answer 4

Какой язык/IDE вы используете?

В .Net вы можете просмотреть потоки приложения:Отладка->Windows->Потоки или Ctrl+Alt+H

Answer 5

Отладка взаимоблокировок может оказаться сложной задачей.Обычно я веду журнал и смотрю, где он останавливается.Я либо записываюсь в файл, либо в консоль отладки, используя OutputDebugString().

Answer 6

Лучше всего начать с добавления операторов журналирования.Как правило, я бы рекомендовал только те общие ресурсы, которые находятся в тупике, но их добавление в целом может указывать на ситуации или области кода, которые вы не ожидали.Широко разрекламированная проблема с базой данных stackoverflow.com на самом деле оказалась log4net!Команда stackoverflow никогда не подозревала о log4net, и только изучение журналов (по иронии судьбы) показало это.Я бы изначально отказался от каких-либо сложных инструментов, например WinDgb, поскольку их использование, ИМХО, не очень интуитивно понятно.