Быстрое снятие задачи.

← →
alpet (2005-02-02 13:51) [0]

При отладке программы постоянно сталкиваюсь с мощнейшим зависаниями (виснет все включая Delphi). Наверно из-за отладки asm кода в котором используется esp для вычислений.

От текущего пользователя практически ничего при этом не удается сделать. Запрос на снятие задачи через taskkill проходит успешно, но при этом процесс остается в живых и висит. Более менее удается снимать задачу запустив taskkill от имени другого пользователя. Как обойти эту проблему под текущим пользователем?

← →
Digitman © (2005-02-02 14:08) [1]

> Наверно из-за отладки asm кода в котором используется esp
> для вычислений

манипуляции с esp в PL3 крайне редко приводят к "зависаниям" ..

если, конечно же, не умудряться специально устанавливать esp таким образом, чтобы он указывал на адреса, распределенные под системные регионы памяти отлаживаемого процесса

> Запрос на снятие задачи через taskkill проходит успешно,
> но при этом процесс остается в живых и висит

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

← →
alpet (2005-02-02 14:37) [2]

1. По моему виновато SEH, оно использует esp. Мне порой удается 3-4 раза сделать trace (F8) и все виснет.

Это я прекрасно понимают. В зависшей системе не удается снять не одно приложение. Блокируется GDI, окна просто не могут нарисоваться. Виснет практически весь Windows, хотя при этом процессор как показывает taskmgr не используется. На повисшем процессе успешно срабатывают функции TerminateThread и TerminateProcess, однако он остается в живых. Но они прекрасно срабатывают из процесса запущенного под другим пользователем.

← →
SammIk © (2005-02-02 21:23) [3]

А причем сдесь сех?

← →
alpet (2005-02-03 12:09) [4]

Я в ассемблерном коде специально делал ошибки, вроде запись по адресу [0], и получал похожие зависания, вместо обработки исключения. В последнее время решил вообще нетрогать esp, уж больно проблем много от него.

← →
Digitman © (2005-02-03 12:22) [5]

> В последнее время решил вообще нетрогать esp

трогать-то его можно, , но с полным пониманием происходящего ..
Борланд же трогает, и еще как трогает ! .. достаточно посмотреть на чуть ли не повсеместно генерируемый код пролога/эпилога ф-ций/процедур, использующих лок.переменные

//фрагмент пролога
push ebp
mov ebp, esp
sub esp, общий_размер_блока_лок_переменных //модифицировали указатель вершины стека

.. что-то

//фрагмент эпилога
mov esp, ebp //восстановили запомненное значение указателя вершины стека
pop ebp

← →
Eraser © (2005-02-03 17:33) [6]

Digitman ©

//фрагмент пролога
push ebp
mov ebp, esp
sub esp, общий_размер_блока_лок_переменных //модифицировали указатель вершины стека

.. что-то

//фрагмент эпилога
mov esp, ebp //восстановили запомненное значение указателя вершины стека
pop ebp

Соответсятвенно если внутри функции произойдёт что-то очень непредвиденное может накрыться весь стек потока... ?

alpet
Попробуй в "опасных" функциях применять другую конвенцию вызовая, через регистры.

← →
Digitman © (2005-02-03 17:41) [7]

> может накрыться весь стек потока... ?

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

← →
alpet (2005-02-03 19:22) [8]

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

← →
Digitman © (2005-02-04 08:42) [9]

> Когда в esp находится 0

а как там ноль оказался ?

← →
alpet (2005-02-04 11:56) [10]

В оптимизированных алгоритмах жутко не хватает регистров, я даже пошел на SMC (подробно на форуме WASM\A&O\Оптимизация и полиморфный код). Вот и esp использовал для хранения различных значений вроде образца для поиска (и как показала практика напрасно).

← →
Игорь Шевченко © (2005-02-04 11:58) [11]

> Вот и esp использовал для хранения различных значений вроде
> образца для поиска (и как показала практика напрасно).

Можно и eip использовать. Или всякие там CR0-CR4, DR0-DR7 :)

← →
Eraser © (2005-02-04 12:01) [12]

alpet
Что самое интересное эти глюки бывают только в режиме отладки...

← →
alpet (2005-02-04 12:01) [13]

Я и отказался собственно. Меня больше волнует суть зависания, до этого я считал что TerminateProcess/TerminateThread всесильные функции по отношению к процессам, на которые хватает прав доступа.

← →
Digitman © (2005-02-04 12:22) [14]

> alpet

> В оптимизированных алгоритмах жутко не хватает регистров

дурью ты маешься.

кто тебе сказал, что оптимизация кода (именно кода, а не алгоритма !) сводится искл-но к минимизации обращений к памяти ?

← →
alpet (2005-02-04 12:32) [15]

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

Что же касается зависаний приходится пока держать cmd запущенный от другого пользователя.

> alpet (04.02.05 12:32) [15]

imho ты пытаешься натянуть человеческие портки на стадо слонов.
не сводятся ли все твои потуги в т.н. "оптимизации" к попытке реализовать в многозадачной среде алгоритмы, требующие ОСРВ ?

> Когда все классические методы исчерпаны

это какие же такие "классические" ?

← →
alpet (2005-02-04 12:47) [17]

Задачи оптимизации временно решены, с этим проблем пока нет (esp везде убран).

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

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

> Вообще вопрос был такой как можно убить повисшее в таких
> случаях приложение

вообще был ответ - "убив" Делфи-процесс, стартовавший отладку дурногго кода.

> вынос инвариантов

с этим и без твоих потуг оптимизатор компилятора прекрасно справляется.

> развертывание циклов

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

> префетчинг

этим заведует кэш-контроллер.

> анализ на спаривание комманд

ощущаешь явную необходимость ? да на здоровье !

> выравнивание адресов доступа к памяти и кэшу

опять же - см. настройки встроенного оптимизатора

p.s.
ты там чего лепишь-то ? систему реального времени что ли ?)

← →
alpet (2005-02-04 16:28) [19]

Насчет "убить Делфи-процесс", иначе говоря текущий отладчик моего процесса. Думаешь я не пытался. Система практически висит, ни одно приложение не откликается, и это все при "свободных" ресурсах ЦП. Убить любой процесс можно только из под другого пользователя.

Кэш, инструкции и прочие траблы подробно объясняются на форумах wasm.ru. Там же и о компиляторах, и их мягко говоря преувеличенных возможностях.

Делаю обыкновенный взломщик игр. С быстрым поиском и отсевом. А вообше можно посмотреть и программу и исходники на www.alpet.hotmail.ru. Если найдешь компилятор под delphi который обгонит (или хотя бы догонит) оптимизированный мной код, я буду очень признателен.

> Если найдешь компилятор под delphi который обгонит (или
> хотя бы догонит) оптимизированный мной код

не понял ? ..

ты супер-пупер-оптимизирующий компилятор что ли лепишь ?
тогда при чем здесь "Делаю обыкновенный взломщик игр" ?
какое отношение генерация оптимального маш.кода имеет к т.н. "взлому" чего-то там ?

> компиляторах, и их мягко говоря преувеличенных возможностях

оптимизирующие компиляторы языков высокого уровня (такие как Object Pascal Compiler) пишутся и предназначены не для самоделкиных, а для специалистов, которым требуется генерация высокопроизводительного кода, реализующего алгоритмы в определенных областях использования ... касаемо Делфи - это кодирование бизнес-алгоритмов, где твоя супер-пупер-оптимизация с фокусами с esp нафих никому не нужна)

← →
alpet (2005-02-04 17:29) [21]

Я человек привыкший, к удобствам, к тому что мой код там где надо работает эффективно. Поиск значений в играх, дело обыденное, и мне гораздо приятнее, когда 300 мегабайтный процесс, моя программа проходит насквозь за 1 секунду и меньше. Другие программы аналоги обычно тратят намного больше времени, порой до дискомфортно.

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

Насчет Delphi, это RAD средство разработки, которая и обычному программисту и системщику позволяет меньше сосредотачиваться на интерфейсе, и больше на коде. Кстати не надо меня относить к самоделкиным, это не обоснованно.

Насколько я понял решения этой проблемы, помимо моего нет...

Быстрое снятие задачи. Найти похожие ветки