Борьба EAccessViolation. Нужны общие идеи

← →
boets © (2003-01-24 11:17) [0]

Время от времени в разных местах возникает EAccessViolation. Вероятно, не освобождаются какие то ресурсы программы. Какие? Как узнать? Нужны какие-нибудь алгоритмы поиска.

← →
Игорь Шевченко © (2003-01-24 11:21) [1]

Общая идея одна - отладчик в руки.

← →
Digitman © (2003-01-24 11:35) [2]

"Access violation at address XXXXXXXX ..."

Берешь значение этого самого XXXXXXXX, стартуешь приложение под встроеннным отладчиком, выбираешь меню "Search | Find Error.." , вводишь XXXXXXXX - и отладчик показывает тебе строку исх.текста, при выполнении которой ты схлопотал AV

← →
Anatoly Podgoretsky © (2003-01-24 11:58) [3]

Лучше бороться с причиной, проблема у тебя при работе с уазателями, недействительные

← →
Юрий Федоров © (2003-01-24 12:04) [4]

Вряд ли это неосвобождение ресурсов. Скорее многократное освобождение(двойное free например). Или ошибки в функциях типа move, freemem, strcopy и др. - причин может быть куча

← →
Smithson © (2003-01-24 12:08) [5]

>>Берешь значение этого самого XXXXXXXX, стартуешь приложение под встроеннным отладчиком, выбираешь меню "Search | Find Error.." , вводишь XXXXXXXX - и отладчик показывает тебе строку исх.текста, при выполнении которой ты схлопотал AV

Фиг! Почти месяц бодался в многопоточном приложении с подобными фичами. Внешним отладчиком видел, что крошится wininet.dll. Но вот выхода на строку, породившую ошибку, не было не разу.

← →
Evgeny V © (2003-01-24 12:12) [6]

Ну еще могу посоветовать CodeGuard

← →
Digitman © (2003-01-24 12:20) [7]

> Smithson

А с какого хрена тебе встр.отладчик покажет строку, если исх.текста wininet.dll нет ?))

> Почти месяц бодался

А нечего бодаться было !)

Если чуть-чуть подумать и почитать хоть что-то на эту тему, то тут же выяснится, что по адресу XXXXXXXX оч легко определить, к коду в ВАП какого модуля процесса относится этот адрес) ... и сразу локализовать именно wininet.dll

← →
Smithson © (2003-01-24 12:30) [8]

Бодался я не с происком источника, а с методами борьбы.
Где случается, нашел быстро. Бвло интересно, что делать, что бы не. :-))

← →
smok_er (2003-01-24 12:38) [9]

Вообще то у меня тоже были аналогичниые глюки с wininet.
Причиной было неправильное декларирование переменных. Например
не так : dwBuffer: array[1..20] of char; а так:
dwBuffer: Сhar;
Причем примеры были взяты из открытых и внушающих доверие источников. В приведенном примере вызывалась функция HttpQueryInfo, причем AV появлялся после отработки функции, которая в функциональном плане была работоспособной.

Так что наверное стоит покопаться в исходниках в этом направлении.

← →
Anatoly Podgoretsky © (2003-01-24 12:49) [10]

Твои источники не заслуживают доверия

ИМХО, нет тут никаких спецсредств, надо работать внимательней.

Например, был такой случай: был TSpeedButton, и я к нему обращался типа так : TSpeedButton(S).Glyph и т.д.

А потом на место TSpeedButton стала приходить TPanel, и Дельфы это проглотили. Но стала иногда падать программа, как раз AccessViolation и выдавала. Вот и ищи отладчиками такое...

В "Debugger Options"->"OS Exceptions" на AV ставишь пипочку в "Handed By": Debugger. Ну и, соответственно, "Stop on Delphi Exceptions".
Собираешь проект с VCL и, если повезет, попадешь в место, где эта бяка вылазит.
Удачи в вашем безнадежном деле!

Проблема то не в WinInet а в данных, которые в нее передают.

Ну как сказать. У меня все решилось после синхронизации вызова создания сокета (обернул его в критическую функцию).

Проблеммы могут возникать если на некий объект реализующий интерфейсы есть ссылки как на объекты и как на интерфейсы. Грабли возникают если забыть что все интерфейсы наследники IUnknown, и в TComponent есть реализация _Realese.

Борьба EAccessViolation. Нужны общие идеи Найти похожие ветки