собственно, номер ревизии - это уже избыточная информация
------------ Дoбавленo:
Nic, в базах я человек серый: вижу пример, добавляю кнопу, нажимаю - падает, говорю "твою маман!", ну и т.д....
Этот топик читают: Гость
Ответов: 9906
Рейтинг: 351
|
|||
карма: 9 |
|
Ответов: 1891
Рейтинг: 110
|
|||
Ну теперь вроде работает нормально:
|
|||
карма: 0 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Если не считать повторного добавления столбцов
Ну и я, как бы, немножко проверял |
|||
карма: 9 |
|
Ответов: 1891
Рейтинг: 110
|
|||
Galkov, писал(а): Если не считать повторного добавления столбцов
Ну и я, как бы, немножко проверял Ну это фигня.... убирается все это ClearAll=True |
|||
карма: 0 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Ну все, сдаюсь...
tsdima, только ты можешь помочь Вот простенький пример: code_8737.txt Каждое нажатие - процесс лочит (теряет надо полагать) новые 4 хэндла Всю башку уже себе сломал... А могу только сказать, где можно НЕ рыться - в дельфячих кодах Проверил, там все делается чистенько, каждый интерфейс перед "установкой" чистится, при выходе из зоны видимости - тоже. Соображает - не придерешься Какое-то дополнительное ругательство для винды сказать надо, наверное... А какое - образования пока не хватает |
|||
карма: 9 |
| ||
файлы: 1 | code_8737.txt [1.3KB] [309] |
Ответов: 2125
Рейтинг: 159
|
|||
fIMalloc - это глобальная переменная, освобождается лишь один раз при завершении программы, а CoGetMalloc делается каждый раз в TDataSource.Create
|
|||
карма: 1 |
|
Ответов: 9906
Рейтинг: 351
|
|||
tsdima писал(а): освобождается лишь один раз при завершении программыЭто не так. Освобождается перед каждой новой "установкой" Говорю же: к дельфячим кодам придраться трудно - разбираются С такой ерундой и я бы разобрался... +к этому: перенос запроса интерфейса в initialization ничего не меняет. Те же +4 хэндла |
|||
карма: 9 |
|
Ответов: 2125
Рейтинг: 159
|
|||
Galkov писал(а): Освобождается перед каждой новой "установкой"Это если установка производится средствами дельфей. CoGetMalloc, которому передаётся адрес переменной, и понятия не имеет, что она уже инициализирована, и тем более, что это переменная дельфячая. Но это к вопросу об утечке памяти, а не хендлов, потому как ... Galkov писал(а): перенос запроса интерфейса в initialization ничего не меняет. Те же +4 хэндлаА вот это странно. Значит где-то ещё косяк. |
|||
карма: 1 |
|
Ответов: 9906
Рейтинг: 351
|
|||
tsdima писал(а): CoGetMalloc, которому передаётся адрес переменной, и понятия не имеет, что она уже инициализированаОн не имеет А вот Дельфи, как это не смешно - ИМЕЕТ, и чистит перед вызовом. И для CoGetMalloc, и для CoCreateInstance... Наверное, атрибут типа [out] помогает tsdima, я честно смотрел коды - чистит, экспериментальный факт |
|||
карма: 9 |
|
Ответов: 2125
Рейтинг: 159
|
|||
Извини за глупый вопрос: ты чем количество открытых хэндлов процесса смотришь?
В Task Manager-е у меня количество хендлов увеличивается только при первом нажатии, потом только память растёт. У меня, правда, и файлов dbf нету |
|||
карма: 1 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Task Manager все это показывает на каждый процесс...
Также как и не закрытый поток при WinExec.doConsoleExec Все честно говорит вроде ------------ Дoбавленo: У меня тоже нету, но Alexbootch научил скопировать PHONE.DBF из ElementsDelphiExampleDateBase ------------ Дoбавленo: Но и без (попробовал удалить) этого файла - +4 хендла (и +память, естественно) на каждое мероприятие... |
|||
карма: 9 |
|
Ответов: 2125
Рейтинг: 159
|
|||
Странное дело: поставил обнуление fIDBInitialize перед CoUnInitialize - утечка памяти заметно сократилась, но стало время от времени увеличиваться количество хендлов, причём не на каждое нажатие, а как-то раз на пятый-десятый на один хендл.
Мне кажется более правильным удалять объект до CoUnInitialize, а не ждать, пока он удалится деструктором после CoUnInitialize. И, кстати, что будет происходить с неудалённым fIMalloc после CoUnInitialize? ------------ Дoбавленo: Вынес
А вот как ты объяснишь тот факт, что если убрать fIDBInitialize := nil, который я добавил в деструктор, то появляется утечка памяти? ------------ Дoбавленo: И кстати, не забудь про StringToOleStr в TDataSource.Initialize |
|||
карма: 1 |
|
Ответов: 9906
Рейтинг: 351
|
|||
tsdima, давай уточним некоторые подробности
И давай будем плясать от того KOLEdb.pas, который лежит на SVN Хотя бы для определенности В котором, кстати говоря, StringToOleStr мной правился на предмет возврата WideString, в отличие от PWChar для библиотечного варианта И для Дельфей - тоже. Есть независимый эксперимент, подтверждающий правильность именно такового: стартовый пример, выложенный коллегой Alexbootch, но с добавкой повторного (от кнопы, с предварительной чисткой таблицы, естественно) запуска OLEdb_Session.doCreate - там старая сессия изничтожается (грубо говоря - ss.free), а новая - создается. Все бесконечно прозрачно: с системным вариантом StringToOleStr - есть утечка памяти, с нашим вариантом - все динамически корректно. Этот вопрос попросту закрыт, как мне представляется. Так вот, возвращаясь к нашим баранам, ну никак не прекращается у меня утечка памяти: хоть выношу (кстати, у меня тоже вынесено) CoInitialize/CoUnInitialize в initialization/finalization, хоть - нет. Ничего не меняется. По нажатию кнопочки счетчик хэндлов ведет себя примерно так: 66-98-105-110-114-118-122-... ну и так далее, выходит на стабильный режим "прибавления четверки" И никаких вразумительных "слов", меняющих это поведение - не нашел Естественно, варианты всевозможных присваиваний nil интерфейсам - тоже пробовал. Еще до того, как стал asm-коды смотреть Это что, у лично у меня такая винда, или приколы XP-Home В кодах баги искать, я уже отчаялся - не нахожу, и все тут Хотя глаз у меня уже "замыленный", конечно... |
|||
карма: 9 |
|
Ответов: 2125
Рейтинг: 159
|
|||
Вот хоть убей, но на моём XP Prof так:
1. Скопировал с SVN: память кушает, хендлы нет 2. Вынес CoInitialize/CoUnInitialize: память кушает, хендлы нет 3. Добавил fIDBInitialize := nil: ни память не кушает, ни хендлы. Другой эксперимент: 1. Скопировал с SVN: память кушает, хендлы нет 2. Добавил fIDBInitialize := nil: память кушает, хендлы тоже, но не на каждое нажатие ------------ Дoбавленo: У тебя MDAC какой версии? Может свежий поставить? |
|||
карма: 1 |
|
Ответов: 9906
Рейтинг: 351
|
|||
tsdima писал(а): У тебя MDAC какой версии? Может свежий поставить?И что это за зверь, и как узнать какой он у меня версии И как его добавить/обновить В принципе, с пол-года назад, винду я полностью "прокачивал" (полный update от Билла)... ------------ Дoбавленo: tsdima писал(а): . Добавил fIDBInitialize := nil: память кушает, хендлы тоже, но не на каждое нажатиеТоже ведь прикол, между прочим... У меня есть подозрение, что Кладов рассчитывал на создание/уничтожение объектов из разных потоков, и на то, что эта фигня имеет некий счетчик ссылок в каждом потоке. В общем, на достойное поведение со стороны Билла. Про "обнуление ручками": до таких глубин работы деструкторов в Дельфи я еще не докопался... Но есть косвенные данные, что свои "истинные объекты" Дельфи правильно обрабатывает (уничтожает попросту) в классах, но не в объектах. По крайней мере, в TControl.Destroy, поля типа String, Кладов обнуляет тоже "ручками" |
|||
карма: 9 |
|