Постоянный рост занимаемой памяти приложением

[@rch1tect0r]

Добрый день.
Я написал приложение на С++, которое должно работать в режиме 24/7, но больше 2х суток оно не работает, т.к. постепенно оно съедает всю виртуальную, а затем и физическую оперативную память(6Гб) В результате ядро убивает это приложение и его требуется перезапустить.

Я пробовал использовать Valgrind чтобы найти утечки памяти и я их нашёл(до этого программа работала только 12-14 часов). Сейчас Valgrind говорит, что никаких утечек памяти нет, но тем не менее я вижу стабильный рост потребляемой оперативной памяти.

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

Приложение многопоточное и достаточно большое, так что выложить его для просмотра кода вряд ли получится, поэтому вопрос что ещё можно предпринять, чтобы понять, что я неправильно написал и требуется исправить?

[aSmile]

Везде, где используешь new используй умные указатели. Тоже писал многопоточный сервер для работы 24/7 - использовал ТОЛЬКО умные указатели (в моем случае это были boost::shared_ptr), и никаких утечек не было (главное циклические ссылки не делать)

[Peter_I]

Для new надо использовать free(), на каждое выделение - соответствующее освобождение перед выходом из подпрограммы
или закрытием потока.

[aSmile]

Для new надо использовать free(), на каждое выделение - соответствующее освобождение перед выходом из подпрограммы
или закрытием потока.

free - это для malloc. Для new - delete

[@rch1tect0r]

Спасибо за советы.
Но использовать умные указатели у меня не получится в виду наличия обусловленной логикой цикличности между отдельными классами.

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

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

[Peter_I]

Для new надо использовать free(), на каждое выделение - соответствующее освобождение перед выходом из подпрограммы
или закрытием потока.

free - это для malloc. Для new - delete

Да, виноват, перепутал. Я, конечно, в программе на Qt использую delete.

[alsoijw]

Спасибо за советы.
Но использовать умные указатели у меня не получится в виду наличия обусловленной логикой цикличности между отдельными классами.

Идея написать своё умный указатель не рассматривалась? Это не так то уж и сложно. Или перейти на язык в котором нет необходимости следить за выделением памяти?

[aSmile]

Но использовать умные указатели у меня не получится в виду наличия обусловленной логикой цикличности между отдельными классами.

Цикличность между классами умным указателям не помеха. Главное, чтобы не было цикличности между объектами. Типа объект a содержит в себе ссылку на объект b, и объект b содержит в себе ссылку на объект a
Пользователь решил продолжить мысль [time]22 Март 2016, 13:45:58[/time]:И еще, возможно у тебя действительно нет утечек, но ошибка где-то в логике - ты не удаляешь данные, когда они уже не нужны. Указатели на эти данные живи, память не течет, но в действительности они уже не актуальны и их надо удалить. Найти такие места сложнее - тут уже надо периодически печатать в лог какую-то статистику (размеры динамических массивов, очередей и т.п.)

[unimix]

Но использовать умные указатели у меня не получится в виду наличия обусловленной логикой цикличности между отдельными классами.

Цикличность между классами умным указателям не помеха. Главное, чтобы не было цикличности между объектами. Типа объект a содержит в себе ссылку на объект b, и объект b содержит в себе ссылку на объект a

В чём разница между цикличностью между классами и между объектами? Да и вроде есть умные ссылки против цикличности.

А по теме (без умных ссылок и сборщиков мусора):
- При создании объекта через new и удалении ссылки на объект удалять и сам объект через delete. (На каждый new должен быть delete).
- Стоит обращать внимание на области видимости ссылки (внутри функции создана временная ссылка с созданным временным объектом, но по завершению функции объект не удаляется).
- Если в классе в свойствах используются ссылки, а объекты создаются в конструкторе или функциях класса, то удалять объекты в деструкторе класса или в соответствующей функции. (В каком классе создаётся объект, в том классе он и удаляется).

[aSmile]

В чём разница между цикличностью между классами и между объектами? Да и вроде есть умные ссылки против цикличности.

Код: (c++) [Выделить]

class B;

class A {
public:
 B* b;
}

class B {
public:
 A* a;
}

int main() {
 A a1;
 B b1,b2;
 a1.b = &b2;
 b1.a = &a1;
 b2.a = nullptr;
 // Классы зависят друг от друга, но цилкической зависимости между объектами нет. Её можно создать b2.a = &a1
}

А умные ссылки против циклических зависимостей объектов - навладеющие, например boost::weak_ptr

[unimix]

aSmile, понял, про что имелось ввиду.

Кстати, в С++11 умные указатели уже в стандартной библиотеке.

[@rch1tect0r]

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

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

[unimix]

@rch1tect0r, не проще ли для начала выводить статистику создания и удаления объектов из конструкторов и деструкторов? Потом посчитать каких объектов создаётся больше, чем удаляется.

[Peter_I]

unimix,
Никогда этого не делал. Автор и так знает, подо что он выделяет память
и точно также должен её вернуть в деструкторе. Если программа графическая,
то надо самому обязательно освобождать память, выделенную под объекты,
не имеющие родителя, а для имеющих это сделает деструктор родителя.

[@rch1tect0r]

@rch1tect0r, не проще ли для начала выводить статистику создания и удаления объектов из конструкторов и деструкторов? Потом посчитать каких объектов создаётся больше, чем удаляется.

Согласно логу всё создаётся и разрушается так как должно.
А те объекты, которые попадают в накопительные буферы, создаются и разрушаются с такой частотой, что лог станет весом в гигабайт за пару минут. Пользы от такого большого лога получается не очень много.
Повторные вызовы конструкторов исключены, потому что я везде для блокировки такого поведения использую boost::unique_lock. Лог тоже подтверждает это. Деструкторы тоже вызываются только один раз.

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

Код: [Выделить]

    Logger::getInstance().info("destructor begin");
   
    /*some actions*/
   
    Logger::getInstance().info("destructor end");
После долгой замены настоящих классов на мнимые нашёл одну закономерность, которая привела к велосипеду, который я написал для перемещение из одного std::list в другой. Произвёл замену моего велосипеда на стандартный метод splice и у меня снизилось выделение памяти.
Теперь только время покажет правильно ли я нашёл проблему или осталось ещё где-то что-то неприятное.