![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Борьба EAccessViolation. Нужны общие идеи [D6, Win2k]
boets © (2003-01-24 11:17:00)Время от времени в разных местах возникает EAccessViolation. Вероятно, не освобождаются какие то ресурсы программы. Какие? Как узнать? Нужны какие-нибудь алгоритмы поиска.
id_privin (2003-01-24 15:37:00) [1]Проблеммы могут возникать если на некий объект реализующий интерфейсы есть ссылки как на объекты и как на интерфейсы. Грабли возникают если забыть что все интерфейсы наследники IUnknown, и в TComponent есть реализация _Realese.
Smithson (2003-01-24 14:30:00) [2]Ну как сказать. У меня все решилось после синхронизации вызова создания сокета (обернул его в критическую функцию).
Anatoly Podgoretsky (2003-01-24 14:06:00) [3]Проблема то не в WinInet а в данных, которые в нее передают.
Паша (2003-01-24 13:58:00) [4]В "Debugger Options"->"OS Exceptions" на AV ставишь пипочку в "Handed By": Debugger. Ну и, соответственно, "Stop on Delphi Exceptions".
Собираешь проект с VCL и, если повезет, попадешь в место, где эта бяка вылазит.
Удачи в вашем безнадежном деле!
cult (2003-01-24 13:13:00) [5]ИМХО, нет тут никаких спецсредств, надо работать внимательней.
Например, был такой случай: был TSpeedButton, и я к нему обращался типа так : TSpeedButton(S).Glyph и т.д.
А потом на место TSpeedButton стала приходить TPanel, и Дельфы это проглотили. Но стала иногда падать программа, как раз AccessViolation и выдавала. Вот и ищи отладчиками такое...
Anatoly Podgoretsky (2003-01-24 12:49:00) [6]Твои источники не заслуживают доверия
smok_er (2003-01-24 12:38:00) [7]Вообще то у меня тоже были аналогичниые глюки с wininet.
Причиной было неправильное декларирование переменных. Например
не так :dwBuffer: array[1..20] of char;а так:
dwBuffer: Сhar;
Причем примеры были взяты из открытых и внушающих доверие источников. В приведенном примере вызывалась функция HttpQueryInfo, причем AV появлялся послеотработки функции, которая в функциональном плане была работоспособной.
Так что наверное стоит покопаться в исходниках в этом направлении.
Smithson (2003-01-24 12:30:00) [8]Бодался я не с происком источника, а с методами борьбы.
Где случается, нашел быстро. Бвло интересно, что делать, что бы не. :-))
Digitman (2003-01-24 12:20:00) [9]
> Smithson
А с какого хрена тебе встр.отладчик покажет строку, если исх.текста wininet.dll нет ?))
> Почти месяц бодался
А нечего бодаться было !)
Если чуть-чуть подумать и почитать хоть что-то на эту тему, то тут же выяснится, что по адресу XXXXXXXX оч легко определить, к коду в ВАП какого модуля процесса относится этот адрес) ... и сразу локализовать именно wininet.dll
Evgeny V (2003-01-24 12:12:00) [10]Ну еще могу посоветовать CodeGuard
Smithson (2003-01-24 12:08:00) [11]>>Берешь значение этого самого XXXXXXXX, стартуешь приложение под встроеннным отладчиком, выбираешь меню "Search | Find Error.." , вводишь XXXXXXXX - и отладчик показывает тебе строку исх.текста, при выполнении которой ты схлопотал AV
Фиг! Почти месяц бодался в многопоточном приложении с подобными фичами. Внешним отладчиком видел, что крошится wininet.dll. Но вот выхода на строку, породившую ошибку, не было не разу.
Юрий Федоров (2003-01-24 12:04:00) [12]Вряд ли это неосвобождение ресурсов. Скорее многократное освобождение(двойное free например). Или ошибки в функциях типа move, freemem, strcopy и др. - причин может быть куча
Anatoly Podgoretsky (2003-01-24 11:58:00) [13]Лучше бороться с причиной, проблема у тебя при работе с уазателями, недействительные
Digitman (2003-01-24 11:35:00) [14]"Access violation at address XXXXXXXX ..."
Берешь значение этого самого XXXXXXXX, стартуешь приложение под встроеннным отладчиком, выбираешь меню "Search | Find Error.." , вводишь XXXXXXXX - и отладчик показывает тебе строку исх.текста, при выполнении которой ты схлопотал AV
Игорь Шевченко (2003-01-24 11:21:00) [15]Общая идея одна - отладчик в руки.