Std::vector и утечки памяти

@Flassie · Регистрация: 03.08.2012

Студворк — интернет-сервис помощи студентам

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

Пример кода:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include <unistd.h>
#include <time.h>
#include <vector>
#include <string>
 
class ShrinkToFitTest {
public:
    ShrinkToFitTest() {
        for(int i = 0; i < 7000000; i++)
            m_list.push_back("111111111111111111");
    }
 
    ~ShrinkToFitTest() {
        m_list.clear();
        m_list.shrink_to_fit();
    }
 
private:
    std::vector<std::string> m_list;
};
 
int main(int argc, char* argv[]) {
    ShrinkToFitTest *a = new ShrinkToFitTest();
    delete a;
 
    sleep(10000);
    return 0;
}

Тестировалось с gcc 4.9.2 и gcc 6.1. ОС - Fedora

Памяти занято при gcc 4.9.2 - ~400 мб VIRT и RES
При gcc 6.1 - ~200мб VIRT и RES

Очистка кеша вручную не помогает

Заранее благодарен за возможные решения

P.S. На винде таких проблем не возникает

@gng · 25.06.2016, 09:48

Flassie, это особенности работы с паматью в libc.
Процесс не отдает память системе на тот случай, что она еще понадобится.
Сисшная malloc_trim(0) должна помочь.
Частично (не думаю, что значительно) может помочь освобождение каждой строки.

@NoMasters · 25.06.2016, 10:33

Проблема в фрагментации кучи.
Стандартный аллокатор из glib возвращает системе свободные страницы только с её вершины. То есть если, условно говоря, выделить двести метров памяти, потом ещё пять и опять двести, а затем высвободить оба больших блока, то системе вернется только последний из них. Это _не_ утечка памяти в прикладном её понимании, т.к. аллокатор будет выделять место в первом пустом блоке при новых вызовах.
Понять, что за данные остались в куче после того, как(казалось бы) всё высвобождено, можно запустив valgrind --leak-check=full --show-leak-kinds=all :

Code
1
2
3
4
5
6
7
8
9
10
11
12
==12864== HEAP SUMMARY:
==12864==     in use at exit: 72,704 bytes in 1 blocks
==12864==   total heap usage: 70,020 allocs, 70,019 frees, 9,791,304 bytes allocated
==12864== 
==12864== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==12864==    at 0x4C2ABD0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12864==    by 0x4EC193F: pool (eh_alloc.cc:123)
==12864==    by 0x4EC193F: __static_initialization_and_destruction_0 (eh_alloc.cc:250)
==12864==    by 0x4EC193F: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:326)
==12864==    by 0x400F4A9: call_init.part.0 (in /usr/lib/ld-2.23.so)
==12864==    by 0x400F5BA: _dl_init (in /usr/lib/ld-2.23.so)
==12864==    by 0x4000DC9: ??? (in /usr/lib/ld-2.23.so)

Это служебные данные самого аллокатора. Место под список выделенных фрагментов, вероятно.

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

@Flassie · 25.06.2016, 11:01 **[ТС]**

Сообщение от NoMasters

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

Можно уточнить на эту тему?

Добавлено через 18 минут

Сообщение от gng

Сисшная malloc_trim(0) должна помочь.

Да, неожиданно, но помогло. Огромное спасибо

@Olej · 25.06.2016, 18:03

Сообщение от Flassie

Проблема проявляется исключительно на Linux

Проблема проявляется как-раз в том, что вы переносите в Linux дурные привычки, приобретённые в другом месте (Windows

).
Определитесь с тем, что вы называете "утечка памяти" и чем вы её меряете.

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

@Flassie · 25.06.2016, 23:05 **[ТС]**

Сообщение от Olej

Проблема проявляется как-раз в том, что вы переносите в Linux дурные привычки, приобретённые в другом месте (Windows).

Дурные привычки - привычная очистка памяти с помощью delete/free?)
Ну вы уж извините)
А когда приложение впустую занимает приличный объем памяти - это не очень нормально, как по мне

Хотя в некоторых случаях, отрицать не стану, это полезно

@Olej · 25.06.2016, 23:18

Сообщение от Flassie

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

Это как по вам... А как по разработчикам операционных систем - это очень даже нормально

. Особенно в многозадачных ОС: когда где-то памяти будет не хватать - вот тогда у вас немедленно её и отберут.
P.S. Вы должны при этом ещё принимать во внимание такие вещи, не очень заметные с уровня пользовательского программирования, как: MMU, отображение логических страниц на физическую память, выделение физической памяти только и исключительно страницами ... и др. подобные вещи.

Сообщение от Flassie

Дурные привычки - привычная очистка памяти с помощью delete/free?)

Я ни слова не сказал ни про delene ни про free.
Дурные привычки это: а). изучать программирование в Windows + б). переносить полученные в Windows стереотипы на другие (нормальные) системы.

@Dmitriy_M · 02.07.2016, 15:03

Сообщение от Flassie

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

Вообще то ОС умеет выгружать редко используемые страницы памяти на HDD/SSD и т.д. Поэтому и есть VIRT и RES.

Новые блоги и статьи Все статьи Все блоги /
Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .	Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.
Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .	Настройки VS Code Loafer 13.04.2026 { "cmake. configureOnOpen": false, "diffEditor. ignoreTrimWhitespace": true, "editor. guides. bracketPairs": "active", "extensions. ignoreRecommendations": true, . . .	Оптимизация кода на разграничение прав доступа к элементам формы Maks 13.04.2026 Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2. Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива. Было так:. . .	Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .

@gng 923 / 639 / 198 Регистрация: 08.09.2013 Сообщений: 1,693
	25.06.2016, 09:48
	Сообщение было отмечено Flassie как решение Решение Flassie, это особенности работы с паматью в libc. Процесс не отдает память системе на тот случай, что она еще понадобится. Сисшная malloc_trim(0) должна помочь. Частично (не думаю, что значительно) может помочь освобождение каждой строки. 1

Std::vector и утечки памяти

Решение