Вверх ↑
Этот топик читают: Гость
Ответов: 9906
Рейтинг: 351
#61: 2008-03-24 23:35:25 ЛС | профиль | цитата
собственно, номер ревизии - это уже избыточная информация
------------ Дoбавленo:

Nic, в базах я человек серый: вижу пример, добавляю кнопу, нажимаю - падает, говорю "твою маман!", ну и т.д....
карма: 9

0
Ответов: 1891
Рейтинг: 110
#62: 2008-03-24 23:59:32 ЛС | профиль | цитата
Ну теперь вроде работает нормально:
Add(MainForm,3171043,210,161)
{
Left=20
Top=105
Height=460
Caption="OLEDBF"
Position=1
}
Add(Label,4277617,203,112)
{
Left=10
Top=110
Width=44
Height=17
Caption="Запрос:"
}
Add(OLEdb,2142462,266,238)
{
Point(onError)
link(onConnect,14252000:doCreate,[])
link(Driver,16491277:Text,[])
}
Add(Button,941652,210,238)
{
Left=305
Top=90
Width=75
Caption="Подключить"
link(onClick,2142462:doOpen,[])
}
Add(OLEdb_Query,11136757,378,238)
{
Text="SELECT * FROM PHONE "
link(onQuery,16321824:doStr,[(426,244)(426,209)])
link(onColumns,5673081:doEnum,[])
link(dbSession,1082019:Data1,[(384,226)(356,226)(356,331)(328,331)])
}
Add(OLEdb_Session,14252000,322,238)
{
Point(onError)
link(onCreate,9808021:doWork2,[])
link(dbHandle,2142462:dbHandle,[(328,226)(300,226)(300,282)(272,282)])
}
Add(StringTable,6078793,504,210)
{
Left=10
Top=235
Width=370
Height=185
Point(doAddColumn)
}
Add(MT_Enum,5673081,441,245)
{
link(onItem,6078793:doAddColumn,[])
}
Add(MT_String,16321824,441,203)
{
link(onResult,6078793:doAdd,[(489,209)(489,216)])
}
Add(Hub,1623322,266,427)
{
OutCount=3
link(onEvent1,10639747:doExec,[(310,433)(310,384)])
link(onEvent2,6078793:doClear,[(401,440)(401,223)])
link(onEvent3,9808021:doWork3,[(361,447)])
}
Add(Label,3324329,203,105)
{
Left=10
Top=10
Width=76
Height=17
Caption="Подключение:"
}
Add(Memo,16491277,266,168)
{
Left=10
Top=30
Width=370
Height=55
Strings=#43:Provider=MSDASQL.1;DSN=Файлы dBASE;DBQ=C:\;|
ScrollBars=2
}
Add(HubEx,9808021,357,231)
{
link(onEvent,11136757:doQuery,[])
}
Add(Button,1248675,210,427)
{
Left=300
Top=205
Width=80
Caption="Выполнить"
link(onClick,1623322:doEvent1,[])
}
Add(OLEdb_Query,10639747,329,371)
{
link(dbSession,1082019:Data2,[])
link(Text,9497040:Text,[(342,359)(377,359)])
}
Add(GetData,1082019,322,287)
{
link(Data,14252000:dbSession,[])
}
Add(Memo,9497040,371,301)
{
Left=10
Top=130
Width=370
Height=70
Strings=#69:INSERT INTO PHONE(LASTNAME,NAME,PHONE,STREET,HOUSE,APP,NOTES) VALUES |54:('Петров','Петр','56789','Садовая','56','6','Редиска')|
}
карма: 0
%time%
0
Ответов: 9906
Рейтинг: 351
#63: 2008-03-25 00:07:38 ЛС | профиль | цитата
Если не считать повторного добавления столбцов

Ну и я, как бы, немножко проверял
карма: 9

0
Ответов: 1891
Рейтинг: 110
#64: 2008-03-25 00:13:44 ЛС | профиль | цитата
Galkov, писал(а):
Если не считать повторного добавления столбцов

Ну и я, как бы, немножко проверял


Ну это фигня.... убирается все это ClearAll=True
карма: 0
%time%
0
Ответов: 9906
Рейтинг: 351
#65: 2008-04-02 10:25:52 ЛС | профиль | цитата
Ну все, сдаюсь...

tsdima, только ты можешь помочь
Вот простенький пример: code_8737.txt
Каждое нажатие - процесс лочит (теряет надо полагать) новые 4 хэндла
Всю башку уже себе сломал...
А могу только сказать, где можно НЕ рыться - в дельфячих кодах
Проверил, там все делается чистенько, каждый интерфейс перед "установкой" чистится, при выходе из зоны видимости - тоже.
Соображает - не придерешься

Какое-то дополнительное ругательство для винды сказать надо, наверное...
А какое - образования пока не хватает
карма: 9

0
файлы: 1code_8737.txt [1.3KB] [309]
Ответов: 2125
Рейтинг: 159
#66: 2008-04-02 15:42:30 ЛС | профиль | цитата
fIMalloc - это глобальная переменная, освобождается лишь один раз при завершении программы, а CoGetMalloc делается каждый раз в TDataSource.Create
карма: 1

0
Ответов: 9906
Рейтинг: 351
#67: 2008-04-02 20:02:26 ЛС | профиль | цитата
tsdima писал(а):
освобождается лишь один раз при завершении программы

Это не так. Освобождается перед каждой новой "установкой"
Говорю же: к дельфячим кодам придраться трудно - разбираются
С такой ерундой и я бы разобрался...

+к этому: перенос запроса интерфейса в initialization ничего не меняет. Те же +4 хэндла
карма: 9

0
Ответов: 2125
Рейтинг: 159
#68: 2008-04-02 21:26:14 ЛС | профиль | цитата
Galkov писал(а):
Освобождается перед каждой новой "установкой"

Это если установка производится средствами дельфей. CoGetMalloc, которому передаётся адрес переменной, и понятия не имеет, что она уже инициализирована, и тем более, что это переменная дельфячая. Но это к вопросу об утечке памяти, а не хендлов, потому как ...
Galkov писал(а):
перенос запроса интерфейса в initialization ничего не меняет. Те же +4 хэндла

А вот это странно. Значит где-то ещё косяк.
карма: 1

0
Ответов: 9906
Рейтинг: 351
#69: 2008-04-02 21:33:33 ЛС | профиль | цитата
tsdima писал(а):
CoGetMalloc, которому передаётся адрес переменной, и понятия не имеет, что она уже инициализирована

Он не имеет
А вот Дельфи, как это не смешно - ИМЕЕТ, и чистит перед вызовом.
И для CoGetMalloc, и для CoCreateInstance...
Наверное, атрибут типа [out] помогает

tsdima, я честно смотрел коды - чистит, экспериментальный факт
карма: 9

0
Ответов: 2125
Рейтинг: 159
#70: 2008-04-02 22:46:48 ЛС | профиль | цитата
Извини за глупый вопрос: ты чем количество открытых хэндлов процесса смотришь?
В Task Manager-е у меня количество хендлов увеличивается только при первом нажатии, потом только память растёт.
У меня, правда, и файлов dbf нету
карма: 1

0
Ответов: 9906
Рейтинг: 351
#71: 2008-04-02 23:03:26 ЛС | профиль | цитата
Task Manager все это показывает на каждый процесс...
Также как и не закрытый поток при WinExec.doConsoleExec
Все честно говорит вроде
------------ Дoбавленo:

У меня тоже нету, но Alexbootch научил скопировать PHONE.DBF из ElementsDelphiExampleDateBase

------------ Дoбавленo:

Но и без (попробовал удалить) этого файла - +4 хендла (и +память, естественно) на каждое мероприятие...
карма: 9

0
Ответов: 2125
Рейтинг: 159
#72: 2008-04-02 23:58:03 ЛС | профиль | цитата
Странное дело: поставил обнуление fIDBInitialize перед CoUnInitialize - утечка памяти заметно сократилась, но стало время от времени увеличиваться количество хендлов, причём не на каждое нажатие, а как-то раз на пятый-десятый на один хендл.
Мне кажется более правильным удалять объект до CoUnInitialize, а не ждать, пока он удалится деструктором после CoUnInitialize. И, кстати, что будет происходить с неудалённым fIMalloc после CoUnInitialize?
------------ Дoбавленo:

Вынес

#pas
initialization
CoInitialize(nil);
finalization
CoUninitialize;
утечка прекратилась.
А вот как ты объяснишь тот факт, что если убрать fIDBInitialize := nil, который я добавил в деструктор, то появляется утечка памяти?

------------ Дoбавленo:

И кстати, не забудь про StringToOleStr в TDataSource.Initialize
карма: 1

0
Ответов: 9906
Рейтинг: 351
#73: 2008-04-03 22:19:37 ЛС | профиль | цитата
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

0
Ответов: 2125
Рейтинг: 159
#74: 2008-04-04 11:23:07 ЛС | профиль | цитата
Вот хоть убей, но на моём XP Prof так:
1. Скопировал с SVN: память кушает, хендлы нет
2. Вынес CoInitialize/CoUnInitialize: память кушает, хендлы нет
3. Добавил fIDBInitialize := nil: ни память не кушает, ни хендлы.

Другой эксперимент:
1. Скопировал с SVN: память кушает, хендлы нет
2. Добавил fIDBInitialize := nil: память кушает, хендлы тоже, но не на каждое нажатие

------------ Дoбавленo:

У тебя MDAC какой версии? Может свежий поставить?
карма: 1

0
Ответов: 9906
Рейтинг: 351
#75: 2008-04-04 14:12:14 ЛС | профиль | цитата
tsdima писал(а):
У тебя MDAC какой версии? Может свежий поставить?

И что это за зверь, и как узнать какой он у меня версии
И как его добавить/обновить

В принципе, с пол-года назад, винду я полностью "прокачивал" (полный update от Билла)...


------------ Дoбавленo:

tsdima писал(а):
. Добавил fIDBInitialize := nil: память кушает, хендлы тоже, но не на каждое нажатие

Тоже ведь прикол, между прочим...
У меня есть подозрение, что Кладов рассчитывал на создание/уничтожение объектов из разных потоков, и на то, что эта фигня имеет некий счетчик ссылок в каждом потоке. В общем, на достойное поведение со стороны Билла.

Про "обнуление ручками": до таких глубин работы деструкторов в Дельфи я еще не докопался...
Но есть косвенные данные, что свои "истинные объекты" Дельфи правильно обрабатывает (уничтожает попросту) в классах, но не в объектах.
По крайней мере, в TControl.Destroy, поля типа String, Кладов обнуляет тоже "ручками"
карма: 9

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