Заметил интересную вещь на своей проге -- при работе она постоянно съедает часть ресурсов памяти, начал искать и обнаружил, что компонент Stack при считывании из него параметров не очищает этот параметр, а оставляет в памяти. При достижении полного считывания память показывает, что Stack полон, нажимаеши очистить -- Stack очищается и освобождает память. Вот небольшой пример.
code_7446.txt
Как производилась проверка. Компилируем и запускаем прогу (лучше не из среды), запускаем диспетчер задач, ищем прогу в процессах и запоминаем количество памяти, нажимаем Add, ждем достижения конца прогресса. Память начинает расти и растет до конца прогресса, а ведь схема построена так, что стэк регулярно считывается, а значит, после достижения конца заполнения память должна освобождаться, но это не происходит до тех пор, пока не нажмешь Clear. В чем тут проблема?

Пальцем покажи

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

Galkov, не удалось показать пальцем: за ~10 мин ("выпил чашечку кофе", перекурил) при загрузке процессора 50% никакого увеличения памяти не призошло code_7448.txt

А схему тогда я зачем привел, чтобы показать? Хорошо, а почему работающая в таком режиме программа пожирает память и не освобождает ее. За две недели программа разрастается до 100 Мб. Достаточно отсоединить все Stack'и и разрастание памяти не происходит. Возможно, данные очищаются нормально, но в PList'e не происходит очистка памяти после стирания указателей. Что-то приводит, ведь, к разрастанию потребляемых ресурсов памяти.

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

Леонид, а ты мою запусти и посмотри.

Приведенная схема НИКАКОГО отношения к утверждению

не имеет.
К такому утверждению имеет отношение более простая схема из 6 элементов

Убедительная просьба, просто отвечать за свои слова
Сказал "обнаружил, что компонент Stack " - показывай

Но в той схеме, достаточно отсоединить Stack от мультика и разрастания памяти не происходит. Как еще я тогда должен считать -- Stack виноват или не Stack? Может и не Stack виноват, но ведь в конце же я спросил

Есть схема, можно на ней показать -- как избавиться от излишнего потребления памяти.

Из этого НЕ следует НИЧЕГО.

А вот из твоего утверждения в виновности Stack СЛЕДУЕТ совершенно категорично, что такая схема будет жрать память неограничено:
code_7449.txt
И ЕСЛИ это не соответствует действительности, ТОГДА не верна исходная посылка

готов схемой из 4х элементов опровергнуть г-на nesco,
code_7450.txt
после первого нажатия диспетчер остановился на 1908Кб и более не увеличивал эту цифру.
------------ Дoбавленo:

опередили

Кстати говоря, ответственность за слова и предполагает самостоятельное проведение элементарных тестов ДО выкладывания утверждения.

бесспорно

Проверил ваши примеры, но не понял -- почему в примере от Dilmы сожрало память, и не освободила ее при считывании? Вот пример от Dilmы с добавлением Clear, при нажатии на него происходит не полное, но освобождение памяти. Как это понимать?
code_7451.txt
Если понажимать по-очередно на клавиши Add/Clear, то можно проследить что память будет менятся в определенных пределах.

вывод напрашивается сам собой: проблема в ОС, программах или отличие от дистрибутива(т.е. соответствие SVN)

В этих компонентах никакого отличия от SVN -- нет, а вот в ОС... очень может быть. В принципе, почему съело память я кажется понял -- при добавлении в стэк была отпущена память на все данные которые в него вошли, а так как в следующем цикле Add мы не увеличиваем колическство данных, вот память и не растет, а освободить память можно только по Clear. Если не правильно понял, то поправьте.

nesco, так растет память или не растет