|
Notes |
|
|
|
Выборочно глянул - всё по-старому.
Эти сообщения об утечках генерятся для "интерфейсов", которые не убиты в деструкторе ввиду отсутствия такового. Как заставить эврекалог анализировать утечки после того как всё сольётся из автоматических деструкторов - я не знаю. |
|
|
|
(0010873)
|
|
zed
|
|
14-03-2013 21:05
|
|
|
|
|
|
Ну просто там какой-нибудь глобальный деструктор более полный, больше разных Fxxx := nil; прописано, вот и вся разница.
Ну коли настаиваешь - погляжу. Я как-то уже пытался понаходить чего не слито, нашёл только не написанные руками автодеструкторы. |
|
|
|
(0010880)
|
|
zed
|
|
15-03-2013 08:09
|
|
|
Такое чувство, что не уничтожается сам TGlobalState и всё что он хранит. |
|
|
|
|
Близко ))
Я тут запустил из-под дельфи с эврикой, поигрался параметрами
UseMozilla=0
UseInternalHttpd=0
(это при том, что сас у мня не в одном экземпляре сейчас запущен).
И обнаружил, что утечка возникает уже при UseMozilla=1 (присто запускаю, жду когда запустится, выключаю).
Так что похоже между DLL и хостом что-то не пролетает, или референс, или эврика. |
|
|
|
(0010904)
|
|
vasketsov
|
15-03-2013 13:16
(edited on: 15-03-2013 14:17) |
|
Не освобождается в момент смерти GState даже TInternalDomainInfoProviderByMapTypeList
а с ним и TZmpInfoSet
потому и тянется всё ))
зы. Один косяк нашёл, не убивается TfrmMarkInfo, ибо не InterfacedObject ((.
|
|
|
|
|
Пописал TfrmMarkInfo на коленке - стало убиваться.
А вот почему TMarkPictureListSimple не умирает - не могу найти.
В общем "утечки" те же самые, в деструкторах подобавлял убийств - сильно не полегчало. Но оставил.
А заходно пофиксил небольшую кучку багов, которые почему-то стреляли только в дебаге (в scriptcontrol и в httpd) и если не повезёт - не давали при закрытии проги ей спокойно умереть. |
|
|
|
|
|
Если в u_BaseInterfacedObject заменить под DEBUG TBaseInterfacedObjectDebug на TInterfacedObject - число утечек уменьшаетя почти вдвое, аттач приаттачен |
|
|
|
(0010915)
|
|
Fetser
|
|
17-03-2013 06:08
|
|
|
Версия Nightly.130317.263 продолжает ругаться (elf приложил) |
|
|
|
|
|
SASPlanet_SACS_0.elf - сгенерён эврикой для 0-й ревизии в SACS. Открыл и закрыл. |
|
|
|
(0010966)
|
|
zed
|
|
03-04-2013 04:41
|
|
Ты просто отнаследовался от неудачной версии. Но похоже, что там потом были доработки, которые к тебе не попали, потому утечка так и осталась.
Кстати, может связано: у САСа сейчас 2 варнига, а у тебя 3. |
|
|
|
|
Я не вижу доработок, касающихся например
Type=TBitmap32StaticStandartSize; Total size=14681632; Count=56 |
|
|
|
|
Вот из интересного:
Type=TUserAccessRights; Total size=72; Count=1
Type=TContentTypeManagerSimple; Total size=964; Count=1
Type=TMarkPictureListSimple; Total size=136; Count=1
Type=TMarkCategoryFactoryConfig; Total size=296; Count=1
Type=TBitmap32StaticStandartSize; Total size=14681632; Count=56
Type=TMarkPictureSimple; Total size=8736; Count=84
В общем-то ноги во многом растут из TMarkPictureListSimple, остальные тащатся по ссылкам за ним.
Рещил разобраться с первым (TUserAccessRights) ибо он новый, его нет в SAS и он ещё не так глубоко размножился, как например MarkPictureList или ContentTypeManager. Всё проверил гд есть, даже with переписал, мало ли компилеру башню снесло - и никаких изменений.
Но закоментировал кусок в самом низу TGlobalState.LoadConfig (прямо целиком if (not ModuleIsLib) then begin end) где:
FUserAccessRights.ReadConfig(MainConfigProvider.GetSubItem('UserAccess_Restrictions'));
FMarksCategoryFactoryConfig.ReadConfig(MainConfigProvider.GetSubItem('MarkNewCategory'));
Естественно при запуске настройки слетели на дефолтные.
Однако при выключении эврека промолчала.
Раскомментировал назад (как было). Запустил. Закрыл. Эврека опять промолчала. И даже точки остановка внутри TMarkPictureListSimple.Destroy и в деструкторе пула битмапок стали посещаться.
Какого хрена данные в ini влияют на подсчёт ссылок, и что такого в ReadConfig делается (или соответственно не делается), что такая хрень происходит - сказать пока что сложно. Но ситуация начинает напрягать. |
|
|
|
|
|
Думаю что связано с метками в SQLite, так как по умолчанию (без ini) метки в SML. |
|
|
|
|
Проблема была в Self в конструкторе TMarksSQLDb.Create.
Заодно поисправлял кучу опечаток, порефакторил и пооптимизировал всякой ерунды. |
|
|
|
(0010973)
|
|
zed
|
03-04-2013 17:46
(edited on: 03-04-2013 17:50) |
|
>Проблема была в Self в конструкторе TMarksSQLDb.Create.
Насколько я вижу, проблема с утечкой ещё жива. К тому же, ещё и кэш SQLite начал высвечиваться в логе.
О, после этого коммита перестало течь :)
|
|
|
|
|
В SQLite были свои утечки, и тоже когда в качестве интерфейса отдаётся Self.
Сейчас эврикалог пишет про утечки в SQLite только если там что-то по исключению валится (например SQL-запрос кривой), хотя исключения душатся и складируются в лог (и что там может утечь и как - пока не могу понять). |
|
|
|
(0010982)
|
|
zed
|
|
03-04-2013 20:11
|
|
|
Ну, этот баг можешь закрывать. Той утечки, о которой была речь уже нету. А что подтекает тестовый SQLite-кэш, так тож ещё в процессе может сто раз полечиться. |
|
SASPlanet.elf (122,707) 15-03-2013 18:12