Как узнать где ошибка delphi

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

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

Однако, несмотря на предупреждение, программа может запуститься. Если вводятся
дкакие-либо данные, то появляется сообщение об исключительной ситуации – exception. При этом программа приостанавливается, переходя из режима исполнения в режим отладки. Чтобы перейти к обычному редактированию кода, лучше остановить программу. Это можно сделать с помощью команды Program Reset. Затем можно поправить ошибку и вновь запустить программу.

В большие программы всегда закрадываются ошибки. Их надо быстро и квалифицированно найти и исправить.

Механизм исключительных ситуаций (exception)
одно из больших достоинств Delphi. С их помощью вы можете контролировать
возникновение ошибок и создавать в результате устойчивые к ошибкам программы.

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

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

Опасность таких скрытых ошибок состоит:

1) в том, что они таятся в той части кода, которую программист написал и уверен, что
она правильная (программа запустилась), а значит, и не очень внимательно будет
искать ошибку;

2) в том, что проявляется эта ошибка совсем в другом месте кода – не в том, в котором
допущена. А это приводит к долгим поискам ее по всей программе.

При возникновении исключительной ситуации можно проигнорировать ее и запустить
исполнение программы дальше, нажав F9. В этом случае программа выдает сообщение об ошибке. Необходимо найти ошибку – понять, в какой строке и почему происходит сбой. Для этого можно воспользоваться трассировкой. Для того чтобы определить первую строчку, начиная с которой будет проводиться трассировка, нужно поставить Breakpoint – точку останова.

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

Чтобы выполнить текущую строку, на которой стоит курсор отладки, нажмите F7 или
F8. Строка выполнилась, и курсор сместился. Если необходимо перейти к следующей строке, то можно нажать F8, если нужно зайти в какую-либо функцию, то нажимают клавишу F7 и продолжают трассировку.

Для того чтобы в ходе отладки узнать значение той или иной переменной, нужно просто подвести к ней курсор. Появится hint со значением этой переменной. Это, однако, работает не со всеми переменными, а только с доступными в данный момент. Если нужно постоянно контролировать значение переменной, то еще проще добавить ее в список Watch.

Для более основательного слежения за значениями можете воспользоваться Списком Наблюдения (Watch List, Ctrl+F5).

Таким образом, при программировании среда Delphi может находиться в различных
режимах:

• Режим редактирования – режим, в котором редактируется код проекта,
модифицируется форма, добавляя на нее компоненты и настраивая их свойства. Это
основной режим.

• Режим исполнения программы – режим, в который среда переходит, как только
нажата клавиша F9 и был построен exe-файл. Фактически, в этом режиме происходиткак раз исполнение получившегося exe-файла проекта. Программа исполняется так,
как если бы ее вызвали не из Delphi, а просто из Windows.

• Режим отладки – в этот режим можно перейти из режима исполнения программы.

При этом программа будет приостановлена (но не остановлена совсем).

Чтобы продолжить трассировку (последовательный переход от команды к команде),
можете воспользоваться клавишами:

• F9 (Run) – продолжить программу, не трассируя ее.

• F8 (Step over) – выполняется текущая строка кода, и переходят к следующей строке.

• F7 (Trace Into) – то же, что и F8, с тем отличием, что если в текущей строчке
содержится вызов какой-либо функции или процедуры, то попадают внутрь этой
процедуры и трассируют ее до конца, затем из нее возвращаетс и переходят к
следующей строке (на которую перешли бы сразу, если бы нажали F8).

• F4 (Run to Cursor) – переход в режим исполнения программы до тех пор, пока не
должна будет выполнена строка, на которой стоит текстовый курсор (аналогично
тому, как если бы была установлена точка останова)

• Shift+F8 (Run Until Return) – процедура выполняется до конца.

• Ctrl+F2 (Program Reset) – остановка трассировки и переход в режим редактирования
кода. (Иногда целесообразнее, если это не грозит ошибками, продолжить исполнение
программы (F9) и выйти из нее нормальным образом, закрыв главную форму).

При работе в Delphi сообщение об ошибке фактически появляется дважды: сначала
выводится окно об исключительной ситуации и программа приостанавливается, а потом,
если нажать F9 (F8, F7 и т.п.), – возникает стандартное сообщение об ошибке Windows.

Итак:

1. Произошла ошибка.

2. Программа приостанавливается.

3. Выводится сообщение об exception. Это сообщение для программиста. Среда Delphi
сообщает, что программа не в состоянии выполнить какую-то свою команду.
Программист не предусмотрел возможность исключительной ситуации. Среда Delphi
приостанавливает программу, чтобы программист разобрался, где и в чем ошибка.
Отключить приостановку (2)–(3) можно, сняв флажок Menu => Tools => Debugger
Options => Language Exceptions => Stop on Delphi Exceptions.

4. Нажатие клавиши F9 (F8, F7 или др.).

5. Выводится сообщение об ошибке. Это сообщение для пользователя программы
(ситуация запуска приложения не из Delphi, а через exe-файл из Windows, т.е. не
существовует пунктов 2, 3, 4).

6. Программа продолжается (при этом она не сумела выполнить ту часть, в которой
произошла ошибка, и значит, если эта часть важная, продолжение может
сопровождаться дальнейшими ошибками).

Механизм обработки исключительных ситуаций заключается в том, что если
произошла ошибка (1) и не надо выводить (5), предпринимаются действия, чтобы (6) исполнялось корректно.

Для этого «опасная» команда (или целый блок) помещается внутрь конструкции try..except..end или try..finally..end.

Блок try..finally..end используется аналогично try..except.., но с тем отличием, что блок
команд между finally и end выполняется в любом случае, вне зависимости от того, было исключение между try и finally или нет.

Нравится ресурс? Помоги проекту!

Узнать где произошла ошибка по имеющемуся адресу

• Подписаться на тему
• Сообщить другу
• Скачать/распечатать тему

Сообщ. #1 , 08.10.10, 19:34

Junior Рейтинг (т): нет

Здравствуйте. Не знал в какой раздел запостить этот топик, но так или иначе. Пишу оболочки на Делфи, и переодически некоторые dll-ки пишу на С++ (посредством Visual Studio), которые в последствии к этой оболочке подключаю. Бывает, в этих dll’ках происходят ошибки, а-ля Access Violation at address 05B47A7 in module ‘blabla.dll’. Вопрос: как узнать в каком месте в dll’ke произошла ошибка зная адрес(05B47A7) ошибки? Сообщение отредактировано: IDontBelieveInSilence — 08.10.10, 19:35

CodeMonkey	Сообщ. #2 , 08.10.10, 19:56
	Пока висит окно — ставьте программу на паузу (вы ведь запускали под отладчиком?), потом Search/Go to address, вводите $05B47A7.

IDontBelieveInSilence	Сообщ. #3 , 08.10.10, 19:59
Junior Рейтинг (т): нет	>Пока висит окно — ставьте программу на паузу (вы ведь запускали под отладчиком?), потом Search/Go to address, вводите $05B47A7. Нет, речь идет о баграпортах которые приходят от пользователей. Например, вот, прислали мне скриншот, мол A/V по адресу хххххх в blabla.dll. И вот, как мне узнать где именно там произошла ошибка, имея на руках только адрес?

Rouse_	Сообщ. #4 , 08.10.10, 20:45
Moderator Рейтинг (т): 320	Обычно достаточно расрутить стек SEH фреймов. Достаточно грамотный пример идет в составе JEDY библиотеки, там как раз помимо этого показано как работать с линкуемой отладочной информацией и MAP файлом.

Romtek

Сообщ. #5 , 08.10.10, 21:51

пропагандист Рейтинг (т): 188

Адрес ошибки имеет значение только на машине клиента. Так что эта информация, на мой взгляд, пользы не несёт. Попробуйте скомпилировать тот модуль (если знаете какой именно или даже все, когда выбора нет) с отладочным журналом (log), ведя учёт времени входа и выхода критических участков кода. Затем попросите клиента прислать вам этот журнал. Нужно знать сначала как воспроизвести ту ошибку, а остальное — дело техники.

northener	Сообщ. #6 , 08.10.10, 22:10
	Цитата IDontBelieveInSilence @ 08.10.10, 19:59 Нет, речь идет о баграпортах которые приходят от пользователей. Рекомендую http://www.eurekalog.com/index_delphi.php

CodeMonkey

Сообщ. #7 , 08.10.10, 22:12

Цитата IDontBelieveInSilence @ 08.10.10, 19:59 И вот, как мне узнать где именно там произошла ошибка, имея на руках только адрес? Никак. Чтобы это узнать, нужно знать актуальный базовый адрес blabla.dll на машине клиента в момент ошибки. Например, адрес ошибки — $05B47A7. blabla.dll была загружена по $0500000. Значит, смещение инструкции кода, вызывавшей ошибку, от начала DLL: $05B47A7 — $0500000 = $B47A7. Вы запустили программу у себя, поставили на паузу. На вашей машине blabla.dll имеет базовый адрес $0610000. Тогда вас интересует адрес $0610000 + $B47A7 = $06C47A7. К таким ситуациям нужно себя готовить заранее. EurekaLog, madExcept, JCL (JclDebug + JclHookExcept).

IDontBelieveInSilence	Сообщ. #8 , 09.10.10, 00:14
Junior Рейтинг (т): нет	>К таким ситуациям нужно себя готовить заранее. EurekaLog, madExcept, JCL (JclDebug + JclHookExcept). В том то и дело, что в случае с Делфи-оболочкой всё решено именно так — у меня интегрирован EurekaLog, но как быть с dll’ками, которые у меня написаны на С++ в Visual Studio 2008? Есть ли для Visual Studio аналог EurekaLog?

northener

Сообщ. #9 , 09.10.10, 01:27

Цитата IDontBelieveInSilence @ 09.10.10, 00:14 >К таким ситуациям нужно себя готовить заранее. EurekaLog, madExcept, JCL (JclDebug + JclHookExcept). В том то и дело, что в случае с Делфи-оболочкой всё решено именно так — у меня интегрирован EurekaLog, но как быть с dll’ками, которые у меня написаны на С++ в Visual Studio 2008? Есть ли для Visual Studio аналог EurekaLog? Тогда не понятно почему вы задаёте свой вопрос именно тут? Мы никогда не отвечали за мелкомягких. P.S. У них есть свои решения, но это уже не сюда.

CodeMonkey

Сообщ. #10 , 09.10.10, 14:11

Ответ на этот вопрос зависит от того, кто обрабатывает исключение в DLL. Если исключение передаётся вам — его должна поймать EurekaLog. Понятно, что вразумительное сообщение об ошибке при этом будет далеко не всегда. Но у вас будет хотя бы стек вызовов. Только вот сам стек вызовов будет нечитабелен — ведь в DLL, написанной на C++, нет никакой отладочной информации в любом «формате Borland» (map, TD и т.п.). Как правило, передавать исключения через границы модулей — плохая идея. Потому что обычно в языке исключение представлено объектом. Программа Delphi не знает, как обращаться с объектами C++, как их читать, как их освобождать (после обработки исключения). Поэтому, DLL обязана обрабатывать все исключения внутри себя, передавая во вне только индикацию ошибки.

0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)

0 пользователей:

• Предыдущая тема
• Delphi: Общие вопросы
• Следующая тема

[ Script execution time: 0,0356 ]   [ 16 queries used ]   [ Generated: 4.06.23, 21:03 GMT ]  

← →
jen_bond
 
(2003-05-11 22:55)
[0]

При закрытие приложения возникает ошибка Access Valiation по адресу ….. Каким образом можно отладить, и найти место где возикает эта ошибка!!!!

← →
default
 
(2003-05-11 22:56)
[1]

напиши код

и всё будет тип-топ

← →
Vasiliy
 
(2003-05-11 23:09)
[2]

Гдето выполняешь Object.Free когда Object = nil

← →
evvcom
 
(2003-05-12 03:07)
[3]

> Vasiliy (11.05.03 23:09)

> Гдето выполняешь Object.Free когда Object = nil



Вовсе нет. На такие ошибки обычно Delphi сама выкидывает в отладчик. В данном случае ошибка выскакивает во время финализации юнитов/проекта. Я недавно такую искал. Оказалось, забыл в деструкторе написать MyComponent.Free; (в конструкторе было MyComponent := TMyComponent.Create(nil);) Т.е. компонент создавался, но за автоматическое уничтожение его никто не отвечал. Аналогично с TObject.

← →
Morfein
 
(2003-05-12 03:54)
[4]

← →
Anatoly Podgoretsky
 
(2003-05-12 08:07)
[5]

← →
Morfein
 
(2003-05-12 10:29)
[6]

← →
Palladin
 
(2003-05-12 10:34)
[7]

> Morfein © (12.05.03 10:29)



если создан и просто уничтожен то можно, но если он еще при уничтожении выставлен в Nil (например FreeAndNil(Obj)), то конечно же нельзя

← →
han_malign
 
(2003-05-12 10:35)
[8]

>Access Valiation по адресу …..

— вообще есть мизерный шанс локализовать строку где возникает ошибка по Map файлу, но в это место отладчик обычно и сам приходит…

← →
Anatoly Podgoretsky
 
(2003-05-12 10:39)
[9]

← →
Mikelson
 
(2003-05-12 10:50)
[10]

Почему бы не скомпилировать проект с debug dcu и по шагам посмотреть весь процесс завершения работы приложения?

← →
default
 
(2003-05-12 14:23)
[11]

заглянули бы в исходник Free и вопросов бы не было…

← →
Palladin
 
(2003-05-12 14:40)
[12]

звиняйте…

реализация free меня все время с толку сбивает, отождествление с Destroy…

procedure TfrMain.OnCreate(Sender: TObject);
 var BadForm: TBadForm;
 begin
   BadForm.Refresh; // причина  ошибки
 end;
 

Попытаемся разобратся в этой ситуации. Предположим, что BadForm есть в списке «Available forms » в окне Project Options|Forms. В этом списке находятся формы, которые должны быть созданы и уничтожены вручную. В коде выше происходит вызов метода Refresh формы BadForm, что вызывает нарушение доступа, так как форма еще не была создана, т.е. для объекта формы не было выделено памяти.
Если вы установите «Stop on Delphi Exceptions » в Language Exceptions tab в окне Debugger Options, возможно возникновения сообщение об ошибке, которое покажет, что произошло ошибка типа EACCESSVIOLATION. EACCESSVIOLATION — класс исключение для недопустимых ошибок доступа к памяти. Вы будете видеть это сообщение при разработке вашего приложения, т.е. при работе приложения, которое было запущено из среды Delphi.
Следующее окно сообщения будет видеть пользователь — и программа будет закрыта при совершение недопустимой операции:

 Access violation at address 0043F193
 in module 'Project1.exe'
 Read of address 000000.
 

Первое шестнадцатиричное число (‘0043F193’) — адрес ошибки во время выполнения программы в программе. Выберите, опцию меню ‘Search|Find Error’, введите адрес, в котором произошла ошибка (‘0043F193’) в диалоге и нажмите OK. Теперь Delphi перетранслирует ваш проект и покажет вам, строку исходного текста, где произошла ошибка во время выполнения программы, то есть BadForm.Refresh.
Естественно, что списка наиболее общих причин ошибок, вызывающих аварийное завершение работы программы, написанной в Delphi в чистом виде нет. Есть несколько общих «узких мест» в коде и структуре программы, когда подобная ошибка может произойти. Перечислим наиболее распространенные.

Недопустимый параметр API

Если вы пытаетесь передать недопустимый параметр в процедуру Win API, может произойти ошибка. Необходимо отслеживать все нововведения в API при выходе новых версий операционных систем и их обновлений.

Уничтожение исключения

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

 Zero:=0;
 try
    dummy:= 10 / Zero;
 except on E: EZeroDivide do
    MessageDlg('Can not divide by zero!', mtError, [mbOK], 0);
    E.free. // причина ошибки
 end;
 

Индексация пустой строки
Пустая строка не имеет никаких достоверных данных. Следовательно, попытка индексировать пустую строку — подобно попытке обратиться к нулю, что приведет также к ошибке:

 var s: string;
 begin
    s:='';
    s[1]:='a'; // причина ошибки
 end;
 

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

 procedure TForm1.Button1Click(Sender: TObject);
 var
   p1 : pointer;
   p2 : pointer;
 begin
   GetMem(p1, 128);
   GetMem(p2, 128);
  {эта строка может быть причиной ошибки}
   Move(p1, p2, 128);
  {данная строка корректна }
   Move(p1^, p2^, 128);
   FreeMem(p1, 128);
   FreeMem(p2, 128);
 end;
 

Вот и всё, Удачи!