Вверх ↑
Этот топик читают: Гость
Ответов: 3889
Рейтинг: 362
#91: 2011-10-22 15:50:28 ЛС | профиль | цитата
Neo писал(а):
постить сюда все подряд ошибки мне неудобно

Все подряд и не нужно, нужно подобрать технологию полу-самостоятельной отладки, а потом выдать результаты на анализ сюда. Будет полезно и Вам, и Вашим последователям. Может даже найдём универсальное решение на будущее.
------------ Дoбавленo в 15.31:
Neo писал(а):
"Access Violation at address 004144B9 ... Read of address 00000000"

1nd1g0 писал(а):
3) Вы ввели адрес не из той строчки, часто их показывается два, один больше другого на 00400000

Обращаю Ваше внимание на то, что когда адрес в понравившейся Вам строчке начинается после ДВУХ нулей и ТРЕТЬЯ цифра больше или равна 4-м, вставлять в указанный мною ключ нужно адрес за вычетом 400000, то есть, по приведённой мною цитате, (004144B9 - 400000) = 000144B9 :
"%fname%" "-U%opath%." -Q -F144B9
Собственно, этот адрес обычно тоже указан в сообщении. ------------ Дoбавленo в 15.50:
[offtop]Всё-таки серьёзность потенциальных ошибок геометрически пропорциональна возможностям создаваемых средой программ. Полномочия приходят с ответственностью [/offtop]
карма: 1

0
Ответов: 704
Рейтинг: 7
#92: 2011-10-22 16:31:04 ЛС | профиль | цитата
1nd1g0, я очень благодарен Вам за помощь! Нашел эту коварную ошибку! Но не нашел истоков - файла hiMainForm_C42550.pas нет и строки 3636 соответственно ))
вот ошибка:
hiMainForm_C42550.pas(3636) Target address found.
WinExec_1517840.Destroy;
карма: 0

0
Ответов: 3889
Рейтинг: 362
#93: 2011-10-22 16:38:54 ЛС | профиль | цитата
Neo писал(а):
файла hiMainForm_C42550.pas

Файл есть! Нажмите в среде CTRL+D перед компиляцией и посмотрите в папку code пакета сразу после неё. Но и без него уже видно строчку с ошибкой.
------------ Дoбавленo в 16.38:
Neo писал(а):
WinExec_1517840.Destroy;
Что, собственно, я и говорил
1nd1g0 писал(а):
Нашёл место возникновения ошибки - она происходит в деструкторе TClassMainForm. Кто-то повредил или неправильно зарегистрировал адрес своего деструктора из таблицы деинициализации.

карма: 1

0
Ответов: 704
Рейтинг: 7
#94: 2011-10-22 17:13:41 ЛС | профиль | цитата
Спасибо! Буду потихоньку избавляться от лишних потоков.
карма: 0

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#95: 2011-10-22 17:28:47 ЛС | профиль | цитата
Neo писал(а):
WinExec_1517840.Destroy;

Похоже, что вот это в деструкторе


  Terminate;

вызывает ошибку. Попробуй его заремарить и прогнать на вылет
карма: 22

0
Ответов: 704
Рейтинг: 7
#96: 2011-10-22 17:32:44 ЛС | профиль | цитата
Кстати, по схеме моего теста МультикаEX комментариев нет?
------------ Дoбавленo в 17.32:
nesco, подскажите, в каком конкретно файле это сделать?
карма: 0

0
Ответов: 3889
Рейтинг: 362
#97: 2011-10-22 17:37:37 ЛС | профиль | цитата
Neo писал(а):
в каком конкретно файле это сделать

HiAsm\Elements\Delphi\code\hiWinExec.pas
6-я строка с конца Поставить перед ней //
карма: 1

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#98: 2011-10-22 17:39:16 ЛС | профиль | цитата
Насколько я понял, то у тебя же вот этот деструктор WinExec_1517840.Destroy; вызывает ошибку, значит ремарить надо в файле hiWinExec.pas
карма: 22

0
Ответов: 704
Рейтинг: 7
#99: 2011-10-22 17:46:27 ЛС | профиль | цитата
Ну а как же что ошибка произошла в hiMainForm - или я неправ?
карма: 0

0
Ответов: 3889
Рейтинг: 362
#100: 2011-10-22 18:14:07 ЛС | профиль | цитата
Neo писал(а):
ошибка произошла в hiMainForm - или я неправ?

И правы, и нет. Произошла она в контексте формы, но глубже по иерархии, в процедуре уничтожения объектов (перед завершением приложения форма по списку уничтожает всё, что из неё было порождено, вызывая процедуры уничтожения), в момент уничтожения связанных с WinExec структур. Ваша ошибка и мой дизассемблер говорят, что разрушена (не инициализирована?) структура/список уничтожения объектов WinExec. Всё это справедливо только (!) если Вы ничего не меняли на схеме после возникновения ошибки и вызвали -Fxxxxx сразу после подтверждения ошибки при закрытии приложения. Можете засунуть этот WinExec в самоуничтожающийся контейнер, которыми Вы интересовались и посмотреть, что будет (там вызывается та же часть кода).
------------ Дoбавленo в 18.14:
Путаница в том, какой модуль виноват, от того, что в скомпилированном виде все эти "объекты" и "деструкторы" свалены в одну кучу и выглядят как столбик вызовов по списку в конце TClassMainForm . Естественно, там никто не пишет, какая именно процедура вызывается, там даже цикла нет, там просто тупой столбик однообразных команд, который я и принял за картинку или звук потому, что ни один психически здоровый программист такого не напишет. [offtop]Но компилятору простительно, у него и не такое встречается, как погляжу, например, бывает сложный вызов по таблице подпрограммы, в которой столбик из нескольких последовательных операций присвоения одних и тех же значений одному и тому же регистру и выход из подпрограммы в конце. Смотришь на трассировке и думаешь, "Что это было? " Издержки автоматизации производства. Компиляторы "кодят" в машинных инструкциях порою страшнее, чем HiAsm кодит для компиляторов [/offtop]
карма: 1

0
Ответов: 704
Рейтинг: 7
#101: 2011-10-22 19:49:29 ЛС | профиль | цитата
Изменения в файл не помогло. Ошибка поменяла адрес, но в том же компоненте. Буду пробовать мультик-суицидник
карма: 0

0
Ответов: 3889
Рейтинг: 362
#102: 2011-10-23 22:54:43 ЛС | профиль | цитата
Neo писал(а):
Изменения в файл не помогло

Попробуйте закомментировать там же inherited; ( c Terminate; и без )
------------ Дoбавленo в 17.01:
Neo писал(а):
Я выждал эту ошибку, и что Вы себе думаете? Да только я ее и видел после нажатия кнопки Ok (других не было, окно ошибки как и на скрине)! Никаких отчетов не создалось почему-то.

1nd1g0 писал(а):
Скорее всего это произошло потому, что у Вас сама программа в себе перехватила исключение.


== Замена обработчика критических ошибок на системный: ==
== Убедитесь, что в настройках: HiAsm - Сервис - Настройка - Общие - Оптимизация - Сжимать EXE = FALSE ==

По умолчанию некоторые базовые ошибки приложение обрабатывает самостоятельно, отображая малоинформативное окно с номером и адресом, после чего приложение/поток благополучно завершается. Процедуры обработки ошибок сокрыты в недрах прекомпилированной системной библиотеки, по умолчанию не доступной для редактирования простым смертным (речь не о тех, кто знает ассемблер, имеет исходные тексты и сможет заставить компилятор их принять вместо системной библиотеки). Прилагаемая утилита:
Add(MainForm,1258002,238,217)
{
Left=20
Top=105
Caption="Exception handler patch"
link(onCreate,7381010:doSearch,[])
}
Add(FileStream,3170003,455,245)
{
Mode=2
Point(doCopyFromStream)
Point(doPosition)
link(onLoad,663500:doConvert,[])
link(FileName,3618322:String,[(461,205)(375,205)(375,283)(363,283)])
}
Add(Stream2Hex,663500,497,245)
{
link(onResult,16348481:doSearch,[])
}
Add(FileSearch,7381010,287,231)
{
Ext="*.exe"
SubDir=1
FullName=1
link(onSearch,3618322:doAdd,[])
link(Dir,7983766:CurrentDir,[])
}
Add(ListBox,3618322,336,231)
{
Left=455
Top=180
Align=5
Layout="Layer H"
WidthScale=50
Point(onDblClick)
Point(String)
Point(Value)
link(onDblClick,3170003:doOpen,[])
}
Add(Dir,7983766,294,175)
{
}
Add(Position,16348481,539,245)
{
Target="31D28D45F4648B0A6489028908C74004"
ShortSearch=1
link(onSearch,13413539:doCalc,[])
}
Add(FastMathParse,13413539,581,245)
{
DataCount=1
MathStr="(((%1 + 1) / 2) - 1)"
ResultType=0
link(onResult,375822:doEvent1,[])
}
Add(MemoryStream,4456313,406,210)
{
Stream=[ZIP0100000078DA3B0C0000C400C4]
}
Add(DoData,14696612,406,259)
{
link(onEventData,3170003:doCopyFromStream,[])
link(Data,4456313:Stream,[])
}
Add(Hub,375822,630,245)
{
link(onEvent1,3170003:doPosition,[(673,251)(673,301)(443,301)(443,272)])
link(onEvent2,14696612:doData,[(656,258)(656,314)(389,314)(389,265)])
}
позволяет исправить это досадное недоразумение. Кладётся в папку рядом с обрабатываемыми приложениями (не запакованными *.exe, то есть в настройках конструктора должна быть отключена оптимизация, возможно, стоит добавить поддержку *.dll). Двойной щелчок по жертве модифицирует файл таким образом, чтобы при возникновении критической ошибки появлялось стандартное окно ошибок Windows, и, при правильной регистрации в системе отладчика, позволяло как минимум получить дамп памяти и расширенную информацию, а как максимум - сразу приступить к отладке на уровне машинных кодов. Инструкция по настройке встроенного отладчика на примере систем NT5.x есть на 5-й страницы этой темы.
Утилита расчитана на самизнаетекакойкомпилятор, перед запуском последнего исправленного приложения утилиту следует закрыть.
------------ Дoбавленo в 22.54:
Кстати, сигнатурный поиск в утилите выше, при перенастройке FileSearch.Ext на *.* сможет пропатчить не только exe, но и dll, и даже HiAsmcompilerугадайте_какой_компиляторSystem.dcu , после чего все последующие приложения этого компилятора будут передавать свои ошибки на обработку установленного в системе отладчика.
карма: 1

1
Голосовали:Neo
Гость
Ответов: 17029
Рейтинг: 0
#103: 2012-02-24 14:51:19 правка | ЛС | профиль | цитата


Редактировалось 2 раз(а), последний 2025-01-10 20:33:53
карма: 0

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#104: 2012-02-24 14:59:30 ЛС | профиль | цитата
5-103-92-178.pool.ukrtel. писал(а):
Вообще MutexThread не требует имени Mutex

Собственно, в схеме MutexThread не включен, а работает локальная секция -- Mode=Local, те защита потока осуществлется на уровне приложения, а не на уровне системы
карма: 22

0
Ответов: 3889
Рейтинг: 362
#105: 2012-02-24 15:14:56 ЛС | профиль | цитата
Собственно, Mutex менее удобен и несколько медлительнее критических секций, я стараюсь пользоваться SafeMode в Local.

карма: 1

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)