Как узнать, где блокировка потока произошла?
Одно из приложения Windows Forms нашей компании имело странную проблему в течение нескольких месяцев. Приложение, работавшее очень надежный для большинства наших клиентов, но на некотором ПК (главным образом с беспроводным соединением LAN) приложение иногда просто, не отвечало больше. (Вы нажимаете на UI, и окна просят, чтобы Вы ожидали или уничтожили приложение).
Я не смог разыскать проблему в течение долгого времени, но теперь я выяснил то, что произошло. Приложение имело эту строку кода
// don't blame me for this. Wasn't my code :D
Control.CheckForIllegalCrossThreadCalls = false
и используемый некоторые фоновые потоки для изменения средств управления.
Нет я нашел способ воспроизвести остановку приложения, отвечающую ошибка на моей dev машине, и разыскал его к строке, где я на самом деле использовал, Вызывают () для выполнения задачи в основном потоке.
Me.Invoke(MyDelegate, arg1, arg2)
Очевидно, где-нибудь была блокировка потока. После удаления
Control.CheckForIllegalCrossThreadCalls = false
оператор и рефакторинг целой программы для использования Вызывают () при изменении управления от фонового потока, проблему (надо надеяться), уводят.
Однако я задаюсь вопросом, существует ли способ найти такие ошибки, не отлаживая каждую строку кода (Даже если я врываюсь в отладчик после того, как приложение прекращает отвечать, я не могу сказать то, что произошло в последний раз, потому что IDE не переходил к оператору Invoke ()),
Другими словами:
Если мои приложения зависают, как я могу выяснить, какая строка кода была выполнена в последний раз?
Возможно, даже на клиентах ПК.
Я знаю, что VS2010 предлагает некоторым назад функцию отладки, возможно, который был бы решением, но в настоящее время я использую VS2008.
3 ответа
Вы, скорее всего, правильно определили виновника, установка CheckForIllegalCrossThreadCalls на false - отличный способ создать случайный тупик. Единственная причина, по которой это свойство вообще существует, - это возможность отладки программ .NET 1.x с ошибками.
Для устранения тупиковой ситуации вам нужно использовать окно Debug + Windows + Threads, чтобы переключаться между различными потоками и просматривать их стеки вызовов. Но, учитывая вероятный характер источника, это будет сложно, поскольку скорее всего, это неуправляемый код, который что-то делает с очередью сообщений или SendMessage (). Код, который вы не писали, и для которого нет исходного кода или символов отладки. Они также имеют тенденцию быть случайными, и в следующий раз тупиковые ситуации могут выглядеть совершенно иначе.
Окна в основном являются небезопасными для потоков объектами. С ними связано очень большое количество состояний. Не только в оболочках классов Windows Forms, но и внутри самой Windows. Надеюсь, вы устранили проблему.
Существует алгоритм для поиска тупиков. Взгляните на эти результаты Google: http://www.google.be/search?hl=en&client=safari&rls=en&q=deadlock+detection+algorithm&revid=1345706645&sa=X&ei=zqsSTPbmJ4qy0gTvtOWFCg&ved=0CD4Q1QIoAA
Возможно, это может вам помочь: http://www.debuginspector.com/index.htm
Это расширение Visual Studio, которое позволяет отслеживать взаимоблокировки и имеет множество других отличных функций для отладки потоков (например, просмотр стека вызовов нескольких потоков без перехода в окно потоков).