Куда делась память?

← →
MegaVolt © (2006-03-03 11:52) [0]

Вот код показывающий потерю памяти. Как избежать потери?
procedure TForm1.Button1Click(Sender: TObject); Var Mem:integer; begin Mem:=GetHeapStatus.TotalCommitted+GetHeapStatus.TotalAllocated; ShowMessage("Теряем память"); Mem:=GetHeapStatus.TotalCommitted+GetHeapStatus.TotalAllocated-Mem; if mem<>0 then ShowMessage(IntToStr(Mem)); end;

← →
Сергей М. © (2006-03-03 12:19) [1]

Нет здесь никакой потери памяти.

Сообщение ShowMessage(IntToStr(Mem)); ты увидишь единожды, при первом клике на кнопке (и это нормально и вполне объяснимо).

После этого хоть миллион раз кликай - условие mem<>0 никогда не будет выполнено.

← →
Сергей М. © (2006-03-03 12:24) [2]

Память никуда не делась.
При первом вызове ShowMessage() Borland Memory Manager взял из кучи требуемое кол-во памяти, но обратно не отдал (пометил в своих структурах как свободную), чтобы при последующих запросах памяти не было нежелательных (с т.з. производительности) обращений к куче.
Считай что это своего рода мешанизм кэширования.

← →
MegaVolt © (2006-03-03 12:27) [3]

Как тогда проверить есть ли утечки в программе или нет? Из самой программы?

← →
Desdechado © (2006-03-03 12:50) [4]

проверить, все ли Create имеют свои Free

← →
MegaVolt © (2006-03-03 12:52) [5]

Ну тут нету вообще Среате а память выделилась. И когда она освободится непонятно. По идее по завершению работы приложения. И получается что проверить это без сторонних прог неполучится?

← →
Desdechado © (2006-03-03 12:57) [6]

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

← →
Сергей М. © (2006-03-03 12:59) [7]

> проверить это без сторонних прог неполучится?

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

← →
MegaVolt © (2006-03-03 12:59) [8]

>главное - не терять память, которая выделяется явно.

Это понятно но когда размеры проги становятся достаточно большими такая проверка занимает время. И не гарантирует точность.

← →
MegaVolt © (2006-03-03 13:02) [9]

> просто ставишь код проверки в итерацию цикла и пишешь результат в лог

Т.е. без ручной обработки никак?

А можно как то заставить сббросить всю свободную но зарезервированную память чтобы увидеть сколько реально занято? Т.е. приложение как то это делает по закрытию. А можно ли это сделать самостоятельно.

← →
Сергей М. © (2006-03-03 13:09) [10]

> приложение как то это делает по закрытию

Приложение вправе вообще этого не делать.
Приложение вправе вызвать в любом месте halt() и немедленно завершить выполнение своего процесса, не следуя никаким более правилам. Приложение так же м.б. принудительно снято пользователем с выполнения "тремя веселыми кнопками".
В любом случае все ресурсы (в т.ч. и ресурсы памяти), которые были заняты процессом приложения в ходе его работы, будут немедленно и безусловно освобождены и возвращены под контроль ОС.

← →
MegaVolt © (2006-03-03 13:12) [11]

>В любом случае все ресурсы (в т.ч. и ресурсы памяти), которые были заняты процессом приложения в ходе его работы, будут немедленно и безусловно освобождены и возвращены под контроль ОС.

Т.е. контроль утечки памяти нужен только для того чтобы моя прога пока работает не заняла всю память? А от системы после закрытия она ничего занять не может?

← →
Сергей М. © (2006-03-03 13:17) [12]

> контроль утечки памяти нужен только для того чтобы моя прога
> пока работает не заняла всю память?

Ну что-то вроде того ..

> от системы после закрытия она ничего занять не может?

После закрытия (неважно каким образом) все неосвобожденные перед этим явно ресурсы процесса (в т.ч. и ресурсы памяти) будут освобождены. Это концептуальное поведение и привелегия ОС.

← →
MegaVolt © (2006-03-03 13:32) [13]

А можно как то дельфяшному менеджеру давать указания сбросить свободную память?

И зачем тогда пишут что дельфи память за динамическими массивами самостоятельно удаляет по завершению приложения? Ведь если это делает ОС то какая разница делает ли что то дельфи ли инет. Ведь результат одинаков. Или я не прав?

← →
Сергей М. © (2006-03-03 13:42) [14]

> можно как то дельфяшному менеджеру давать указания сбросить
> свободную память?

Нельзя.
Но можно подменить менеджер памяти.
См. TMemoryManager type

> Ведь если это делает ОС то какая разница делает ли что то
> дельфи ли инет.

Если дворник всегда уберет за тобой мусор, то какая разница, уберешь ли ты его за собой или не уберешь ?

← →
MegaVolt © (2006-03-03 14:20) [15]

>Если дворник всегда уберет за тобой мусор, то какая разница, уберешь ли ты его за собой или не уберешь ?

Никакой если дворнику платить за объём выполненной работы платить не нужно.

← →
Сергей М. © (2006-03-03 14:29) [16]

> MegaVolt © (03.03.06 14:20) [15]

Но сорить при этом ты имеешь право лишь на "отведенной" тебе территории.

По аналогии это виртуальное адресное пространство твоего процесса.
Выше этих своих "штанов" выпрыгнуть ты не сможешь.

← →
Игорь Шевченко © (2006-03-03 14:39) [17]

Есть хорошая программа MemProof

← →
MegaVolt © (2006-03-03 14:40) [18]

>Есть хорошая программа MemProof

Есть. Но к сожалению пользоватся я ей не очень умею :( Если бы был примерчик приложения с показанными шагами по отлову утечек...

← →
Сергей М. © (2006-03-03 14:51) [19]

Лучше бы ты привел пример своего кода, в котором ты сомневаешься на тему утечек

← →
MegaVolt © (2006-03-03 14:58) [20]

>Лучше бы ты привел пример своего кода, в котором ты сомневаешься на тему утечек

Вот пример в самом первом сообщении.
А реальная программа достаточно большая с кучей потоков обращений к апишным функциям, работой с потоками и пр...
Вот я взял и проверил. Оказывается утечки есть. Решил их локализовать убрал потоки, убрал почит всё и осталась только то что написано в самом начале. Т.е. получается выловить где у меня память пропадает методом заремливания частей неполучится :(

← →
Игорь Шевченко © (2006-03-03 14:58) [21]

> Но к сожалению пользоватся я ей не очень умею

А к ней разве Readme нету ?

← →
Сергей М. © (2006-03-03 15:06) [22]

> MegaVolt © (03.03.06 14:58) [20]

Приводи реальный фрагмент..

← →
MegaVolt © (2006-03-03 15:34) [23]

>Приводи реальный фрагмент..

Выложить 30К кода? А выделить кусочек где есть потери я не могу потому что не знаю как :( Ибо даже на ShowMessage ругается. Т.е. можно выделить кусочек там одна цифра потерь. Можно взять чуть поменьше там другая. Т.е. отделить код где точно нету от того где есть я не могу. В этом то и проблема.

>А к ней разве Readme нету ?

Есть :) Как запустить и получить результаты я понимаю но вот как по результатам найти место где у меня утечка я не очень понимаю.

← →
Сергей М. © (2006-03-03 15:41) [24]

А ты уверен что есть утечки ?

На основании чего ?

Изложи подробно ...

← →
Сергей М. © (2006-03-03 15:42) [25]

А ты уверен что есть утечки ?

На основании чего ?

Изложи подробно ...

← →
Сергей М. © (2006-03-03 15:42) [26]

А ты уверен что есть утечки ?

На основании чего ?

Изложи подробно ...

← →
MegaVolt © (2006-03-03 16:06) [27]

>А ты уверен что есть утечки ?

Ну несколько симптомов:
1. При каждом тестировании цифра изведённой памяти разная.
2. Она достаточно большая порядка полуметра :(

Как в MemProof посмотреть после закрытия где была выделена память которая не освобождена?

← →
MegaVolt © (2006-03-03 16:14) [28]

Точнее порядка 50К

← →
Сергей М. © (2006-03-03 16:29) [29]

> 1. При каждом тестировании цифра изведённой памяти разная.

Перво что приходит в голову - разные условия тестирования при каждом оном сеансе ...

> 2. Она достаточно большая порядка полуметра :(

Сие не есть факт утечки ..

← →
MegaVolt © (2006-03-03 16:32) [30]

>разные условия тестирования

ага разные.

>Сие не есть факт утечки ..

И как понять есть она или нет? Только анализом кода специалистом?

← →
Сергей М. © (2006-03-03 16:40) [31]

Ну отчегоже ? ProcessEplorer от, например, sysinternals.com, даст возможность любому "непродвинотому" юзеру проконтролировать ресурсы памяти интересующего процесса

← →
MegaVolt © (2006-03-03 16:46) [32]

>ProcessEplorer от, например

Что то я невижу где он ресурсы памяти показывает. Возможно под 9x это недоступно. Да и вообще эта зверюга упала когда я свою прожку запустил :))

← →
Amoeba © (2006-03-03 18:04) [33]

> Вот код показывающий потерю памяти.

Откуда дровишки? С помощью чего установил этот факт? Если это показал ProcessEplorer, то с чистой совестью забей. А если MemProof... тогда ищи ошибки в своем коде.

>Откуда дровишки?

Запусти код :)

На сайте где лежит последняя версия MemProof есть хелп к предидушей... Я понему разобрался за пол часа...

>Я понему разобрался за пол часа...

Я тоже попробовал разбиратся :)
Делаю пустую форму компилирую. Запускаю МемProof и вижу потери памяти :( Причём конкретику где они произошли посмотреть не могу.
Запускаю мемпроф для своей проги вижу потери где то в недрах ComCtrl в MemoryStream по 20 байт на поток. И что мне с этим делать? Править генетический код или как?

> MegaVolt © (06.03.06 10:17) [36]

Странный ты товарисч..

Никто еще не жаловался на мемлики в Д5-приложении, содержащем одну-единственную заведомо пустую форму, без кода введенного явно "ручками", а у тебя эти самые мемлики при тех самых условиях откуда-то вдруг появились ни с того ни с сего ...

>Странный ты товарисч..

Ты уверен что именно я странный а не установленный у меня комплект програмного обеспечения?

>Никто еще не жаловался на мемлики в Д5-приложении

Выложить скриншет?

> Выложить скриншет?

Лучше выложи код проекта и код модуля формы

Нету никакого кода. Просто создать новое приложение и скомпилить его.

> Нету никакого кода

Нет кода - нет и проблемы.

> создать новое приложение и скомпилить его

.. и никаких утечек там не будет.
Не выдумывай небылиц.

> Никто еще не жаловался на мемлики в Д5-приложении, содержащем
> одну-единственную заведомо пустую форму

MemProof жалуется. В одном месте - MakeObjectInstance

http://www.thedelphimagazine.com/samples/1328/1328.htm

> MemProof жалуется. В одном месте - MakeObjectInstance

Ну и что ?

Да мало ли какая хрень на что-то "жалуется" !

Она, эта хрень, имеет ли отношение к ВММ ? ..

Сергей М. © (09.03.06 16:38) [43]

Ты ссылку почитай - утечка есть.
И утечка в этом месте, в MakeObjectInstance

Block := VirtualAlloc(nil, PageSize, MEM_COMMIT, PAGE_EXECUTE_READWRITE);

При вызове FreeObjectInstance эта область памяти не освобождается.

> Crash Coredump © (09.03.06 17:22) [44]

> ссылку почитай

Там речь идет о конкретных условиях, при которых возможна утечка.

Цитата из статьи в моем вольном переводе :

"Утечка обнаруживает себя в дельфийских библ-ках при специфических условиях.
Наиболее важное условие - ссылка на юнит Controls где-то в юнитах DLL-проекта.
Следующее условие - сборка DLL-проекта без ран-тайм пакетов.
И наконец, DLL должна загружаться/выгружаться в динамике"

Эти условия, насколько я понимаю, никак не пересекаются с условиями, при которых автор этой ветки проводит тестирование : "пустой" EXE-проект GUI-приложения, с одной-единственной "пустой" формой.

> Сергей М. © (10.03.06 08:42) [45]

> Эти условия, насколько я понимаю, никак не пересекаются

Если даже утечки нет в конкретном случае (отдельное приложение,
статическая библиотека и т.д.), то, почему бы, и не ругнуться.
Оснований, IMHO, достаточно. Хотя, как оно с MemProof не знаю.

--
Regards, LVT.

← →
olegus81 (2006-03-10 15:30) [47]

unit Un_simple_Mem_test;

interface

implementation

uses
Windows;

var
msg: string;

initialization

finalization

if AllocMemCount > 1 then
begin
Str (AllocMemCount, msg);
msg := msg + " heap blocks left";
MessageBox (0, PChar(msg), "Memory Leak", MB_OK);
end;

end.

Куда делась память? Найти похожие ветки