Вопрос об отладчике

Похож существует также способ сделать его использование RegEx и XPathNavigator для оценки выражения. У меня не было шанса протестировать его все же, но мне отчасти понравился он, потому что это не потребовало, чтобы скомпилировать код во времени выполнения или пользоваться библиотеками, которые не могли быть доступными.

http://www.webtips.co.in/c/evaluate-function-in-c-net-as-eval-function-in-javascript.aspx

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

8
задан Mick 28 September 2009 в 17:18
поделиться

4 ответа

Ваша проблема в том, что GetWindowText фактически отправляет сообщение другому окну и ожидает его возврата. Если это окно принадлежит другому потоку, ожидающему критического раздела, GetWindowText будет ждать вечно.

Вы застряли внутри GetWindowText,

5
ответ дан 5 December 2019 в 11:26
поделиться

Как следует из предыдущих ответов, ваш код застрял внутри «Stuff A».

Могу я предложить другой инструмент для вашего инструментария?

Обычно мне намного проще отлаживать проблемы собственной синхронизации с помощью WinDbg. просто запустите свою программу в WinDbg, укажите на правильные символы, и вся информация будет прямо там для вашего расследования с помощью команд! locks,! cs и k.

Если вы новичок в WinDbg, вы обнаружите, что Интернет полон информации об этом. Я также рекомендую прочитать Расширенная отладка Windows .

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

4
ответ дан 5 December 2019 в 11:26
поделиться

Assuming your question is "Is this normal", then yes, the debugger usually shows the statement after the one stuck on a critical section.

0
ответ дан 5 December 2019 в 11:26
поделиться

Обычно зеленая стрелка рядом со строкой кода означает, что «это следующая строка, которая будет выполнена, если бы не тот факт, что мы застряли где-то в более глубоком фрейме стека». Однако VS не дает возможности сказать наверняка на основании предоставленной на данный момент информации ...

[РЕДАКТИРОВАТЬ - конечно, глубокое знание Win32 может дать очень хорошее предположение - см. Ответ "mos" для вероятного объяснения, основанного на известных ловушках API GetWindowText ()]

Как уже упоминалось, что Visual Studio показывает, что иногда вводит в заблуждение. Чтобы получить более полное представление о том, что именно происходит, вам нужно отключить некоторые бесполезные «функции», которые VS включает по умолчанию. В Инструменты -> Параметры -> Отладка -> Общие убедитесь, что:

  • Включить отладку на уровне адресов = ВКЛ
  • Включить только мой код = ВЫКЛ
  • Включить поддержку исходного сервера = ВКЛ

Это должно позволить вам to:

1) прервать / перешагнуть / и т. д. точную инструкцию, которая вызывает тупик

2) просмотреть полную трассировку стека до этого момента, независимо от модуля (модулей)

3) см. исходный код по возможности, предполагая, что ваш символ & исходные серверы настроены правильно

6
ответ дан 5 December 2019 в 11:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: