Проблемы с памятью

← →
ki11er (2003-09-18 14:50) [0]

Есть большое приложение, написанное на Delphi. При длительной работе оно начинает притормаживать. По диспетчеру задач видно, что вроде как растет количество используемой памяти. Но бодания с MemProof, BoundsChecker и Purify ни к чему не приводят - они показывают, что все ок.
В чем может быть проблема?

Спасибо.

← →
Digitman © (2003-09-18 14:56) [1]

> В чем может быть проблема

в ошибках алгоритма

← →
ki11er (2003-09-18 15:13) [2]

какого алгоритма?
Если имеется в виду, что программа постоянно выделяет память и не освобождает до выхода, то такого нет - проверял уже. Дэлфийный счетчик блоков не растет.

← →
Digitman © (2003-09-18 15:17) [3]

> Дэлфийный счетчик блоков не растет.

а что такое "дэлфийный счетчик блоков" ?

← →
ki11er (2003-09-18 15:21) [4]

> а что такое "дэлфийный счетчик блоков" ?

мда...
AllocMemCount

← →
Digitman © (2003-09-18 15:36) [5]

> ki11er

) ..слышал звон, да не знаешь где он)

ты вообще комментарии читал к этой ф-ции ?
ты вник, в КАКИХ конкретно случаях актуальна и достоверна эта инф-ция ?

← →
Digitman © (2003-09-18 15:43) [6]

сколько экз-ров менеджеров памяти существует в ВАП процесса, столько и разных показаний ты получишь вызовом упомянутой ф-ции в каждом из тех прогр.модулей, которые используют отдельный менеджер

читай внимательно комментарии к ф-ции и сравнивай существующие у тебя условия с теми, для которых описано отдельное поведение ф-ции

← →
ki11er (2003-09-18 15:55) [7]

> ) ..слышал звон, да не знаешь где он)

8-D Вот именно!
Во-первых, это не функция, а переменная.
Во-вторых "программный модуль" только один.
В-третих, раз уж на то пошло, как определить, сколько мэнэджеров существует в скомпилированном приложении и как получить к ним доступ?

← →
Digitman © (2003-09-18 16:06) [8]

> это не функция, а переменная

не суть как важно

> "программный модуль" только один.

на основании чего ты утверждаешь это ?

> сколько мэнэджеров существует в скомпилированном приложении
> и как получить к ним доступ

надо уяснить, как программные модули взаимодействуют в твоем приложении, как они собраны линкером, используются ли run-time packages, где и как

← →
ki11er (2003-09-18 16:09) [9]

ну расскажи про все случаи.
или хотя бы некоторые...

← →
Digitman © (2003-09-18 16:12) [10]

> ki11er

а почитать ? коментарии в хэлпе к тому, о чем речь ведешь ?

← →
ki11er (2003-09-18 16:22) [11]

в коментариях (по крайней мере в тех, о которых идет речь) про мэнэджеры ничего не сказано. Упоминается функция GetAllocMemCount, про которую я что-то не могу ничего найти...

← →
Digitman © (2003-09-18 16:26) [12]

зато там сказано про run-time packages и static-dinamic loaded libraries ... это ОЧЕНЬ важный момент !

← →
Digitman © (2003-09-18 16:29) [13]

> ki11er

ты пойми, что переменных AllocMemCount столько, ксолько экземпляров System.pas загружено в ВАП процесса !

← →
ki11er (2003-09-18 16:32) [14]

не сомневаюсь ;-)
только все как-то наоборот... там правильно написано?
ты хочешь сказать, что
"своя переменная AllocMemCount" = "свой мэнэджер памяти"?
как-то не совсем логично тогда, что при статик линковке получаем несколько менеджеров, а при рантайм - один. По идее, все с точностью до наоборот должно быть.

← →
ki11er (2003-09-18 16:33) [15]

да, между прочим,
ВАП - это что?

← →
Digitman © (2003-09-18 16:51) [16]

> ki11er

> ВАП - это что?

ВАП = Виртуальное Адресное Пространство процесса

> как-то не совсем логично

гораздо логичней для начала было бы посмотреть, какие компоненты ты используешь, и используют ли они BPL в принципе..

это раз

кр.того, твой код (где бы он не находился, в каком бы модуле, как бы этот модуль ни линковался) может неявно использовать какие-то системные или 3rd-party DLL, где речи о борландовском менеджере вообще не идет.. и которые тоже вполне могут запрашивать блоки непосредственно из куч процесса

просмотри все зависимости всех модулей своего слинкованного проекта (включая по цепочке межбиблиотечные зависимости)... с этого надо начать, прежде чем делать какие-то умозаключения

← →
Murad © (2003-09-18 16:54) [17]

2ki11er
2Digitman
Простите что вмешиваюсь в Ваш диалог... возможно просто это
поможет ki11er. Есть утилита под Delphi... MemorySleuth
(TurboPower), в ней очень удобно утечки ловить

← →
ki11er (2003-09-18 16:56) [18]

> с этого надо начать, прежде чем делать какие-то умозаключения

Нет, прежде нужно сначала со своим кодом разобраться, а уж потом чужой ковырять...
Вопрос остается в силе. Сколько дэлфийных мэнэджеров памяти будет в "ВАП" при условии использования "голого" дэлфи (т.е. только стандартные компоненты из поставки) в случаях:
1. Статическая линковка всех библиотек
2. Рантайм билиотеки (опять же все)
3. Часть библиотек статическая, часть - рантайм
...
И как добраться до _всех_ мэнэджэров в этих случаях?

← →
ki11er (2003-09-18 17:04) [19]

Murad
Я знаю про эту штуку. Но она как бы не дешевая... Можешь поделиться?

← →
Murad © (2003-09-18 17:10) [20]

Он у нас в конторе есть, но я не знаю, покупной он или нет... а начальника который санкцию может дать - то же сейчас нет... я ему вечером позвоню, если он разрешит - то кину по почте, ты только адрес мне почтовый свой дай, если в форуме светить его не хочешь, просто напиши мне письмо.

← →
Digitman © (2003-09-18 17:14) [21]

каждый программный модуль, построенный в виде BPL/DLL (и, соответственно, динамически или статически подгружаемый в run-time твоим процессом), имеет собственный экземпляр менеджера

когда же ты ведешь речь о статической линковке КОНКРЕТНОГО МОДУЛЯ (т.е линковке этого модуля на этапе сборки конкретного проекта, а не линковке в ран-тайм !), то следует четко понимать : в этом модуле будут использованы DCU, которые будут ссылаться на один-единственный экземпляр system.dcu

← →
ki11er (2003-09-18 17:27) [22]

Я веду речь о "птичке" "Build with runtime packages". Что будет в случае, когда она включена и что будет, когда выключена?

← →
Verg © (2003-09-18 17:39) [23]

А что показывает AllocMemSize?

← →
Digitman © (2003-09-18 17:39) [24]

> когда она включена

то текущий собираемый проект в ран-тайм будет грузить и использовать указанные внешние BPL, каждая из которых содержит свой собственный экз-р модуля System

> когда выключена

линкер попытается включить в исп.код DCU, каждый из которых в ран-тайм будет обращаться одному и тому же экз-ру модуля System в составе тек.собираемого проекта

← →
ki11er (2003-09-18 17:50) [25]

> то текущий собираемый проект в ран-тайм будет грузить и
> использовать указанные внешние BPL, каждая из которых содержит
> свой собственный экз-р модуля System

> линкер попытается включить в исп.код DCU, каждый из которых
> в ран-тайм будет обращаться одному и тому же экз-ру модуля
> System в составе тек.собираемого проекта

Логично...
Но,
1. Но в хелпе-то не так написано: "Applications that use runtime packages and do not use any statically linked DLLs can safely access AllocMemCount directly."
2. Птичка у меня отключена, так что возвращаемся к началу дискуссии.
3. Что все-таки насчет GetAllocMemCount?

← →
Verg © (2003-09-18 17:53) [26]

Повторю:

А что показывает AllocMemSize?

← →
ki11er (2003-09-18 17:57) [27]

> А что показывает AllocMemSize?

Суммарный размер выделенных блоков.
Тоже не растет - держится в определенных пределах.

← →
Digitman © (2003-09-18 17:59) [28]

> Но в хелпе-то не так написано

правильно написано.

> Птичка у меня отключена

зато возможно некоторые прилинкованные в билд-тайм DCU могут в ран-тайм обращаться к иным библиотекам, в т.ч. и к 3rd-party BPL

единый же борландовский менеджер будет использован либо
- в случае когда ни одна BPL не используется
- в случае когда все ран-тайм модули (и EXE и BPL и DLL) собраны с модулем ShareMem и обращаются, соотв-но, к единой библ-ке BorlandMM.dll, реализующей менеджер памяти

← →
ki11er (2003-09-18 18:16) [29]

> > Но в хелпе-то не так написано
> правильно написано.

Тогда ты не совсем прав.

> зато возможно некоторые прилинкованные в билд-тайм DCU могут
> в ран-тайм обращаться к иным библиотекам, в т.ч. и к 3rd-party
> BPL

Не могут, так как никаких бэпээлей нет на диске _физически_

← →
Verg © (2003-09-18 18:20) [30]

> Тоже не растет - держится в определенных пределах.

Значит кто-то все же ползуясь недельфозным МП (или его другой копией) забывает возвращать память.
Было у меня такое, когда я в одном потоке, чтобы не делить время со штатным МП (главный поток) использовал вместо getmem localalloc. Ну и забывал иногда про LocalFree.

← →
ki11er (2003-09-18 18:42) [31]

2 Verg
Логично...
Но никакие программой dll не используются (по крайней мере по собственной инициативе, т.е. не считая тех библиотек, которые подгружает система - типа спулер и т.п.)

← →
Владислав © (2003-09-18 18:46) [32]

> Digitman ©

Слушайте, Вы последнее время стали таким нудным... Я первый, кто об этом говорит? Надеюсь, что я не прав ;)

> ki11er (18.09.03 14:50)

Скажи, сколько, по твоему мнению, утекает памяти. За какое время (Ну типа скорость)

В чем может быть проблема?

Да в чем угодно. Много возможностей возникновения проблемы тебе Digitman описал. В остальных постах, быть может, тоже истина скрывается.

Зачастую, многие "проблемы с утечкой памяти" основываются на виндовозном диспетчере задач. Если это не мегабайты за неделю с постоянным ростом "утечки", а килобайты за минуту без последующего прироста, то, может, и беспокоиться не стоит. Может это диспетчер памяти.

← →
Verg © (2003-09-18 18:48) [33]

Я и не говорил про dll.

> Но никакие программой dll не используются

Но и чудес же не бывает.

← →
Владислав © (2003-09-18 18:51) [34]

> Verg © (18.09.03 18:48) [33]

Ага. Фантастика.

← →
ki11er (2003-09-18 18:56) [35]

> Скажи, сколько, по твоему мнению, утекает памяти. За какое
> время (Ну типа скорость)

Это довольно сложно оценить, так как сначала течет медленно, потом (где-то через неделю-две) - по экспоненте ;-)

← →
ki11er (2003-09-18 18:57) [36]

> Но и чудес же не бывает.

Согласен. Но что делать? Типа алгоритма - проверь то, посмотри это и т.п. А то только общие рассуждения - я такие советы и сам могу тоннами давать ;-)))

Я тебе советую - проверь localalloc никто не делает (и при чем тут dll?)

> ki11er (18.09.03 18:57) [36]

Блин, выложи код на FTP. Мы начнем искать ошибку (утечку памяти) в твоей программе и перестанем давать глупые советы...

Или погоди... Счас я настроюсь на телепатию или телекинез... Не пугайся, если клавиши будут "сами" нажиматься...

← →
ki11er (2003-09-18 19:21) [40]

> Я тебе советую - проверь localalloc никто не делает (и при
> чем тут dll?)

Проверить проверю, но 99%, что этого нет.

> Блин, выложи код на FTP.

;-) Мег 10 исходников 8-? Да и не могу - денег стоит ;-)

← →
ki11er (2003-09-18 19:23) [41]

> (и при чем тут dll?)

dll при том, что обычно они имеют свои внутренние мэнеджеры памяти...

> Владислав

> нудным

"нудизм" - не самое плохое средство самовыражения)))

> ki11er

чудес не бывает
сделай лок.хук, в нем перехвати все вызовы WinAPI, работающие с кучей, и отслеживай, какие модули процесса в какое время и при каких обст-вах их вызывают

> Проверить проверю, но 99%, что этого нет.

ММ...
перечислите способы (функции), которыми можно взять памяти у виндов.
После этого появится список-план проверок на оставшийся процент.

После этого отанется только сера.... или что там против чертей...?

> Digitman © (19.09.03 08:05) [42]

Получается самовыражаться? ;-)

> ki11er (18.09.03 19:21) [40]

;-) Мег 10 исходников 8-? Да и не могу - денег стоит ;-)

Тогда придется юзать телепатию...

> Владислав

тебе видней, сударь)

← →
ki11er (2003-09-19 13:49) [47]

> Ну как там с памятью то? Поделись результатом плиз.

Не так быстро ;-)
Я этим уже где-то полгода с переменным успехом занимаюсь ;-)

> ki11er (19.09.03 13:49) [47]

Это чем это? Отжиранием памяти? Полгода? Может чего посоветовать? Блин, я иногда память "случайно" отжираю, а люди тут мучаются! Слушай, я в отжирании памяти большой специалист. Может и правда подсказать?

← →
ki11er (2003-09-19 16:26) [49]

Если есть дельные советы - готов выслушать. За этим и здесь...

Проблемы с памятью Найти похожие ветки