Russian Qt Forum

Всем здрасти!

Может кто сталкивался с подобной проблемой.

Есть структурка:


Есть список данных структур:
Есть функция, которая заполняет этот список данными.

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

Откуда ты узнаёшь, что память не освобождается?

Смотрю на резидентную память по htop

Освобождаемость памяти нужно проверять по деструкторам. Добавь в структуру деструктор и в нём debug сообщение - как пить дать оно будет показываться.

Это уже сделано, деструктор чистит все, но по htop память остается. Вычитал, что QList может только разрастаться, но сужаться уже ни как. Вопрос теперь, а как же эту гадость удалить теперь? почистить?

Версия Qt? ОС?

List спокойно чистится и ничего не оставляет. Приведите цифры пожалуйста, например

Правильно, эта память остается за процессом и он может ее использовать по своему усмотрению. Уже 100500 раз обсуждалось.

Бред.

Все удаляется и ничего чистить не надо. Если вашему процессу понадобиться память, то она не будет запрашиваться у ОС, а будет использоваться уже распределенная.

Много раз слышал эту легенду, но не знаю ни одного места где Qt держало бы "резерв памяти".

QList::clear() освобождает все (по крайней мере начиная с версии 4.7). Др дело если распределили напр 1 миллион элементов, а потом удалили и оставили всего 1. Да, там хвостики останутся, но то же самое и std контейнерами 

Причем здесь Qt и какой резерв памяти?

Igors вот тут вы в роли незнающего. :)

Это режим взаимодействия ОС и процесса. Можете почитать.

Вообщем проделал я следующий эксперимент.

Взял два QList'а, первый заполнил 10-тью мегабайтами, т.е. 10 элементов, каждый по 1 мб. Взял его зачистил при помощи метода clear(), по htop, как было занято 10 мб, так и осталось. Далее начал во второй QList добавлять по 1 мб, 10 таких добавлений не изменили размер процесса в памяти, а вот уже 11 итерация прибавила 1 мб к памяти процесса. Вывод следующий: ядро Linux резервирует память под процесс. Не ясно следующее, почему если в той же самой функции где шло заполнение контейнера, сразу для него вызвать clear(), то память освободится, а вот если уже допустим в деструкторе чистить, то память не освобождается. Догадки следующие: ядро считает, что если я в функции занял определенный участок памяти и тут же его удаляю, то нужно этот участок памяти оставить системе, а вот если уже создал и дальше работаю с ней, то и в будущем моему процессу понадобится такой вот участок памяти, банально, но фиг знает может так и есть.

Пробовал также у самого QList'а "пропатчить" метод reserve(), а именно комментил условие, что если пытаются зарезирвировать меньшее число чем сейчас есть, то не делать реалок памяти, я думал, что если так сделаю, то смогу при отчистке сделать просто reserve(0) моему контейнеру, а в итоге шиш, что еще раз подтверждает тот факт, что ядро линукса оставляет память за процессом.

эта память может быть занята другим приложением по первому требованию.

А этот процесс как нибудь контролируем допустим посредством API. Чтобы принудительно отдать память системе?

Нееет :) Хотя в линуксе всё может быть :D

На Mac OSX (linuх posix) штатная утилита Activity Monitor четко показывает что clear() все отдает. А что там делает та или иная версия Linuх - ее личное дело, повлиять на это все равно нельзя (на уровне прикладной программы). В общем, как в том анекдоте "это просто трусы линяют"  :)

Это почему?
Есть brk/sbrk, которой вы сможете регулировать размер распределенной памяти (и под MAC OSX, скорее всего, в том числе).
Только пока вы используете стандартный менеджер кучи, вам это вряд-ли понадобиться, ибо этим занимается он.

Версия Linux тут не причём, всё упирается в версию malloc. Везде они разные. Через LD_PRELOAD можно её легко подменить любому приложению (не статик, конечно).
Кстати, Mac OSX это надстройка над Darwin, которая к linuх не имеет никакого отношения, т.к. выросла из FreeBSD)

Насколько я помню, эти старомодные ф-ции меняют размер сегмента данных, а не кучи.

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

Linuх, FreeBSD, Darwin - во всяком случае одно "nix" семейство. Возвращаясь к теме - ответ тот же - оставить как есть и полагаться на ОС

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

Это для вас он не уместный и я даже знаю почему, это не FindReplace для std::string написать. :)

Ну так если для Вас уместный - реализуйте и выкладывайте здесь, обсудим  :)

Воспользоваться сторонним МП (менеджер памяти), благо их хватает.

Опять-двадцать пять...
Причём здесь ОС, если МП по сути является частью приложения?

Практически тоже самое наблюдал сейчас под Windows. При старте приложухи по диспетчеру задач она заняла 8 мб памяти. После работы и очистки памяти был всплеск до 27 мб, но сбросилось до 10 мб по окончанию, получается куда то делись 2 мб памяти, неужели винда ведет себя также как Linux. Чтобы выяснить это - решил сделать следующий эксперимент: запустил первый процесс при запуске также 8 мб, после работы 10 мб. Начал запускать еще копии таких же приложух, пока не забил всю свободную оперативную память и в тот момент когда уже начал лезть в своп, начал наблюдать завораживающую взгляд картину, первый процесс стал "худеть", сначала сбросил с 10 мб до 7 мб, а потом и вовсе до 2,5 мб. Вуаля, вывод: реально мое тестовое приложение занимает в оперативе 2,5 мб все остальное место он себе натырил как бобер за щеки - на будущее, а как системе стало не хватать оперативы, она начала забирать резервированную память у процессов. Вот такая вот интересная картина получается...

А что в этом вопросе с вами можно обсудить? Вы же понятия не имеете о чем идет речь:


 ;D