How to become an author
Search
Write a publication
Pull to refresh

Comments 48

> 520168 байт и выше — освобождение проходит нормально

Вы бы сначала почитали как работают аллокаторы памяти прежде чем писать «разгромную» статью. Это же классическое поведение аллокатора: маленькие объекты выделяются в общей куче, а за большими — обращаемся к системному аллокатору.
Total votes 20: ↑17 and ↓3+14
Но это не повод так глючить. Ведь выделение маленькими блоками типично для классических (учебных) алгоритмов на списках, графах и т.п.
Total votes 8: ↑6 and ↓2+4
А то, что не производится нормальная дефрагментация кучи — это конечно же баг.

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

Также интересно что автор имел ввиду. Или его компилятор действительно вызывает разные malloc() в этих случаях (в чём я сомневаюсь), или написанное не соответствует наблюдениям.
Total votes 5: ↑0 and ↓5-5
Вообще практически все стандартные реализации malloc/free не возвращают память операционке, а придерживают ее для «своего» процесса. Таким образом овобожденная память в таск менеджере не видна, но достпупна для malloc'a.

Учите матчасть вобщем.

>>Однако при попытке выделить память из другого класса (либо статической функции) мы получим исключение
Бред, такого быть не может, т.к. не может быть никогда. Память либо доступна в рамках всего процесса, либо нет, точка.
Total votes 10: ↑8 and ↓2+6
> Бред, такого быть не может, т.к. не может быть никогда.

Теоретически — может. Компилятор может вызывать разные malloc() или malloc() может раскручивать стек. Конечно на практике, так никто делать не будет так как нет смысла.

> Память либо доступна в рамках всего процесса, либо нет, точка.

Вообще-то есть thread-aware аллокаторы.
Total votes 5: ↑4 and ↓1+3
А вот в Стандартной библиотеке C++, к примеру, можно хоть каждый std::vector создавать со своим собственным аллокатором.

Я к тому, что в программе вполне могут уживаться вместе несколько разных аллокаторов, иногда — даже незаметно для программиста.
Total votes 3: ↑3 and ↓0+3
Как раз в Task Manager она видна как освобожденная.
This comment wasn’t rated yet0
>> Бред, такого быть не может, т.к. не может быть никогда. Память либо доступна в рамках всего процесса, либо нет, точка.
А если выделить пытались из другой арены? Тогда всё сходится, система процессу памяти больше не даёт, свободных мест в нужной арене нету, а из других арен по какой-то причине не получается взять свободный кусок.
Total votes 1: ↑1 and ↓0+1
Эм, рекомендую обратиться к функции _heapmin(). Эта функция соответственно зовет HeapCompact(), которая освобождает в систему пустые страницы из хипа. Обратите внимание — не все выделенное, а только те страницы, которые не содержат выделенных кусочков.

Как подсказывает мне мой склероз, это известная шутка микрософтовских программистов под названием «память в системе бесконечна», и существует она с начала времен. В NT 3.5 уже было именно такое поведение, емнип.
Total votes 7: ↑7 and ↓0+7
Которая, к сожалению, не обеспечивает красивого кросс-платформенного кода.
Хотя VirtualAlloc ее тоже не обеспечивает…
This comment wasn’t rated yet0
Хех, если б это было единственной проблемой. А так даже время получить — и то задача для #ifdef. Ну вот к примеру

#include "timeval.h"

#ifndef HAVE_GETTIMEOFDAY
#ifdef WIN32
#include <mmsystem.h>
static int gettimeofday(struct timeval *tp, void *nothing)
{
#ifdef WITHOUT_MM_LIB
  SYSTEMTIME st;
  time_t tt;
  struct tm tmtm;
  /* mktime converts local to UTC */
  GetLocalTime (&st);
  tmtm.tm_sec = st.wSecond;
...
  tmtm.tm_year = st.wYear - 1900;
  tmtm.tm_isdst = -1;
  tt = mktime (&tmtm);
  tp->tv_sec = tt;
  tp->tv_usec = st.wMilliseconds * 1000;
#else
  /** Time calculations using GetLocalTime had a time resolution of 10ms.The timeGetTime, part
   ** of multimedia apis offer a better time resolution of 1ms.Need to link against winmm.lib **/
  unsigned long Ticks = 0;
  unsigned long Sec =0;
  unsigned long Usec = 0;
  Ticks = timeGetTime();

  Sec = Ticks/1000;
  Usec = (Ticks - (Sec*1000))*1000;
  tp->tv_sec = Sec;
  tp->tv_usec = Usec;
#endif /* WITHOUT_MM_LIB */
  (void)nothing;
  return 0;
}
#else /* WIN32 */
/* non-win32 version of Curl_gettimeofday() */
static int gettimeofday(struct timeval *tp, void *nothing)
{
  (void)nothing; /* we don't support specific time-zones */
  tp->tv_sec = (long)time(NULL);
  tp->tv_usec = 0;
  return 0;
}
#endif /* WIN32 */
#endif /* HAVE_GETTIMEOFDAY */


Я помню в этот кусок еще быстрый способ получения времени добавлял, а то вышенарисованный для Win32 зело тормозен. Нечто вроде такого вписывал

  LARGE_INTEGER li;
  FILETIME ft;

  GetSystemTimeAsFileTime(&ft);
  li.HighPart = ft.dwHighDateTime;
  li.LowPart = ft.dwLowDateTime;
  tp->tv_sec = (long)(li.QuadPart / 10000000LL); // 10^7 as in 100ns units
  tp->tv_usec = (long)((li.QuadPart % 10000000LL) / 10);


Это Curl.
Total votes 3: ↑2 and ↓1+1
Знакомые строки…
Но хотелось всегда красивого.

В итоге обычно все обрамляется #ifdef, а потом вся некрасивость прячется :-)
This comment wasn’t rated yet0
Ну, насколько я понимаю, в линуксах с управлением памятью сильно проще: brk(), да юзай. malloc всего лишь надстройка над этим.
Total votes 2: ↑1 and ↓10
… только все используют mmap().
Total votes 2: ↑2 and ↓0+2
А в чём профит использоания mmap с MAP_ANONYMOUS? (я так понял, речь про него). Всё равно же адресное пространство выделять надо (т.е. brk двигать).
This comment wasn’t rated yet0
Нет никакого brk. Есть замапленые и незамапленые страницы. А преимущество например, в том, что с mmap() может быть несколько аллокаторов, а с sbrk() только один.
This comment wasn’t rated yet0
Ничего не понимаю. Что такое «замапленные страницы»? Давайте для начала определимся, мы про файлы, или про анонимный мапинг?

Полагаю, что таки анонимный.

При вызове анонимного мапинга нужно передать свой указатель на доступный виртуальный адрес. Чтобы адрес стал доступным, надо его разрешить — то есть поднять break point.

Насчёт sbrk — с ним могут работать несколько аллокаторов сразу, правда, dallocate при этом не получится, да.
Total votes 1: ↑1 and ↓0+1
> Ничего не понимаю. Что такое «замапленные страницы»? Давайте для начала определимся, мы про файлы, или про анонимный мапинг?

Нет принципиальной разницы. В файловом маппинге backing store — файл, в анонимном — swap.

Есть страницы замапленные (cat /proc/self/maps) и незамапленные, обращение к которым ведёт к segfault.

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

И передача этого адреса является только советом для mmap() и ничего не гарантирует. Этот адрес может быть не замаплен, но, например, ОС решила запретить его мапить (например, нулевой адрес — см. sysctl vm.mmap_min_addr) или процессор может не поддерживать его мапить (http://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details).

> Чтобы адрес стал доступным, надо его разрешить — то есть поднять break point.

Нет единственного break point. Посмотрите /proc/self/maps у чего-нибудь посложнее, чем ls (например firefox). Страницы данных мапятся вплоть до гранулярности в 1 страницу.

> Насчёт sbrk — с ним могут работать несколько аллокаторов сразу, правда, dallocate при этом не получится, да.

Только если нет TOCTOU гонки между проверкой текущего break и установкой нового.
Total votes 2: ↑2 and ↓0+2
Ок, возможно, я что-то не понимаю.

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

У программы есть brk, который двигает end_data_segment. В пределах этой памяти приложение может писать куда угодно (ну, не считая адресов, отведённых под text).

Теперь программа хочет сделать mmap. Она передаёт адрес, который больше end_data_segement с этого момента [addr;addr+length] становится доступным (в соотв. с флагами) для приложения?

Т.е. в сегменте данных образуется дыра? А что тогда sbrk() после очередного mmap()'а «глубоко вверх» вернёт?
This comment wasn’t rated yet0
Теперь программа хочет сделать mmap. Она передаёт адрес, который больше end_data_segement с этого момента [addr;addr+length] становится доступным (в соотв. с флагами) для приложения?
Адрес — это совет. Какой именно адрес вернёт mmap — это решает система. И он не обязан начинаться сразу за концом «сегмента данных».

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

Допустим, располагается она «далеко» от «сегмента данных» — в чём проблема-то?
Total votes 2: ↑2 and ↓0+2
> Значит, у нас есть сегмент кода, данных, стека и т.д.

Нет. Это в исполняемом файле есть секции кода и данных. Они мапятся в плоское адресное пространство. Плоское (flat) адресное пространство плоское потому что у нас всего один *сегмент*, на который указывают все сегментные регистры (cs, ds, ss). Поэтому для интерпретации адреса не нужно знать из какого он сегмента, потому что сегмент один и тот же.

Но кроме исполняемого файла есть, например, библиотеки со своими сегментами. И всё это посегментно мапится в адресное пространство. При этом сегменты кода, естественно, не идут последовательно. И сегменты данных тоже. (см. опять таки /proc/PID/maps)

> У программы есть brk, который двигает end_data_segment.

Эмм… С точки зрения программиста — да, системный вызов brk что-то там двигает. На практике — он просто мапит/анмапит страницы в конец того что вы называете «сегментом данных».

brk [1] вызывает do_brk [2], который в результате создаёт anonymous mapping.

[1] lxr.linux.no/#linux+v3.6.6/mm/mmap.c#L246
[2] lxr.linux.no/#linux+v3.6.6/mm/mmap.c#L2161
Total votes 1: ↑1 and ↓0+1
> Но кроме исполняемого файла есть, например, библиотеки со своими сегментами. И всё это посегментно мапится в адресное пространство.

сегментами -> секциями.
This comment wasn’t rated yet0
а какая связь между malloc и операционной системой? аллокатор же не в ОС в данном случае, а в libc.
Total votes 3: ↑2 and ↓1+1
Подобная проблема проявляется при работе node.js под высокими нагрузками. Если процесс нагружается задачами, которые он не успевает выполнять (например запросы приходят быстрее чем процесс успевает отвечать на них), процесс node.js начинает выделять память, RSS и Heap растут параллельно. Когда нагрузка спадает и процесс разруливает оставшиеся задачи, GC очищает heap, а RSS память не освобождается. При следующей подобной нагрузке Heap и RSS опять растут параллельно, но после освобождения Heap (при падении нагрузки) RSS остаётся на занятом уровне и так далее. Многих очень волнует такое поведение node.js. Я создавал баг-репорт относительно этой проблемы с небольшим примером, на котором она воспроизводится.

Однако Ben Noordhuis написал, что это не баг, а известная стратегия работы malloc и привёл небольшой пример на С++, иллюстрирующий это поведение. Конечно понятно, что ситуация приведённая в моём примере синтетическая и встречаться в хорошо написанных приложениях не должна, но бывает, что она встречается. Это может быть не самый оптимальный код или DDoS атака или просто резкий набор популярности, на который приложение не рассчитано. Так или иначе, это странно, что память после этого не возвращается системе. Когда Heap занимает 80Mb, а RSS — 3Гб появляются вопросы «а нормально ли это?» и «что делать?».

Было бы здорово, если бы кто-то из хабралюдей, более близкий к C++ смог понятнее разъяснить данное поведение malloc node.js (V8), в частности.
Total votes 3: ↑3 and ↓0+3
А не проще было бы уже заmmapится на что-то большое и работать там уже себе спокойно?
Total votes 1: ↑1 and ↓0+1
Это большое самому пилить на кусочки разных размеров?
Total votes 2: ↑2 and ↓0+2
При работе с большим количеством объектов всегда возникают ситуации, когда стандартные библиотечные решения «в лоб» не работают или работают неудовлетворительно. Например, как-то я сканировал дерево каталогов диска и хранил в памяти имена всех файлов. На большом диске львиную долю времени стали занимать операции создания и уничтожения std::string; кроме того, стало не хватать памяти. Пришлось делать собственную реализацию контейнера строк большого размера, который работал, выделяя куски памяти размером порядка мегабайта и размещая строки в них. Но все равно, контейнер std::map, в котором хранились просто указатели на все эти строки, создавался и уничтожался несколько минут реального времени. Так что пришлось и этот контейнер переделывать, адаптируя его под решаемую задачу.
This comment wasn’t rated yet0
У std-шных контейнеров можно указать свой аллокатор
This comment wasn’t rated yet0
Это «нестандартное поведение» зовется windows memory manager, и описано в документации. Почитайте на досуге — узнаете для себя много интересного… Нормальной работе системы оно не мешает (окромя тормозов, и задержки на garbage при завершении программы), зато позволяет например уменьшить количество access violation, при недобросовестном использовании.
Довольно часто, для вещей пользующих много памяти маленькими кусками пишется собственный ММ.
Total votes 1: ↑0 and ↓1-1
Как видно, мне помешала и довольно сильно…
За наводку спасибо, поизучаю.
This comment wasn’t rated yet0
зато позволяет например уменьшить количество access violation, при недобросовестном использовании.


Это не «зато», а «увы».
За «недобросовестное использование» надо бить по рукам через AV чем раньше, тем лучше.
И баг быстрее выявится, и потенциальных дыр с чтением чужих освобождённых данных меньше.
Total votes 1: ↑1 and ↓0+1
Где-то видел что-то вроде блога об истории windows, где было прямо сказано, что подобное поведение в своё время было ещё в Win 95 как раз ради какой-то игры с подобным недобросовестным кодом.
Т.е. «в теории» можно было педантично исправить, но на практике оказалось бы, что эта игра запускается под DOS но вылетает на Windows. И тогда поведение менеджера памяти сознательно сделали таким — ради совместимости с этой игрой.
This comment wasn’t rated yet0
Вы плохо помните, работа менеджера менялась ТОЛЬКО для старой игры.
Total votes 3: ↑3 and ↓0+3
Дак я не сказал, что это есть хорошо… и не в коем случае не оправдываю MS за это.
Хотя опять же с какой стороны смотреть — в windows очень много стороннего не опенсорсного proprietary — хотите ли вы, чтоб ваша программа, использующая что-то из того, обвалилась в никуда, причем у вас нет возможности заглянуть в источники.
Второй момент, что многие средства разработки предоставляют механизмы словить такой доступ к памяти на стадии разработки — например VS при дебаге в free забивает освобожденную память определенной дрянью, как раз чтобы проще и быстрее выявить такой доступ к ней познее. Проблема в том, что не все из этой области (seg fault) можно поймать на стадии разработки и/или в дебаге.
Добавим сюда многопоточность и т.д. и т.п. — тогда я вам уже не скажу, какое из двух зол я бы выбрал в продакшн.
Total votes 2: ↑0 and ↓2-2
> в windows очень много стороннего не опенсорсного proprietary — хотите ли вы, чтоб ваша программа, использующая что-то из того, обвалилась в никуда

О, интересно: проприетарностью кода оправдывают «невысокое» качество этого «кода».

> Второй момент, что многие средства разработки предоставляют механизмы словить такой доступ к памяти на стадии разработки — например VS при дебаге в free забивает освобожденную память определенной дрянью

Ага, позволяют. Только пример неудачный: забивать память определённым паттерном — это прошлый век. Берите современные инструменты, например, AddressSanitizer.
Total votes 2: ↑1 and ↓10
О, интересно: проприетарностью кода оправдывают «невысокое» качество этого «кода».
А вот передергивать не надо — где я это написал? — проприетарность кода часто есть невозможность заглянуть в исходники. Остальное ваши домыслы…
… это прошлый век. Берите современные инструменты, например, AddressSanitizer.
Вы это мне? Вы там слово например видимо незаметили.
К слову, (незаметив ваше «например») для сей/сей++ под виндами использую Rational Purify — ваш Sanitizer там даже близко не лежал.
Total votes 2: ↑1 and ↓10
> Остальное ваши домыслы…

Вот только не нужно пытаться исправиться. Вы сказали то, что сказали:

> в windows очень много стороннего не опенсорсного proprietary — хотите ли вы, чтоб ваша программа, использующая что-то из того, обвалилась в никуда,

> для сей/сей++ под виндами использую Rational Purify — ваш Sanitizer там даже близко не лежал.

И какой оверхед у Purify, использующего динамическое инструментирование?
This comment wasn’t rated yet0
Оверхед, как оверхед — ест больше памяти, прога работает чуть медленнее, иногда заметно медленнее и ест заметно больше памяти. Стек вроде не жрет, так как Sanitizer. Тут можно почитать, что они сами думают, правда из доки от solaris. Для винды такого линка не нашел.
Total votes 1: ↑0 and ↓1-1
> зато позволяет например уменьшить количество access violation

Вот уж оказывают медвежью услугу, лучше уж сразу пусть по рукам бьет, чем «прощает» опасные ошибки.
Total votes 1: ↑1 and ↓0+1
Довольно часто, для вещей пользующих много памяти маленькими кусками пишется собственный ММ.

Неужели это правда? Как-то это противоречит современной тенденции пользоваться везде, где можно, готовыми библиотеками и не изобретать велосипеды.
Total votes 1: ↑1 and ↓0+1
Огда я прикручивал Доуг Ли аллокатор к одной из своих либ, то читал что это стандартный маллок, используемый в гцц. Возможно поэтому на линуксах все нормально отработало.
This comment wasn’t rated yet0
Тогда он должен быть подвергнут излишней фрагментации…
Попробую на досуге протестировать или глянуть исходник.
This comment wasn’t rated yet0
Чтобы понять, если ли утечка памяти или нет, необходимо в большом цикле повторить выделение/освобождение памяти. Если память потечет — это будет отчетливо видно в диспетчере задач. А то, что аллокатор закэшировал кусок памяти — это ни о чем не говорит. Как было написано, он может использовать этот буфер для выделения маленьких блоков.

Код получится типа такого:
int main(void)
{
	const int blockCount = 1024;
	const int blockSize = 1024*1024;
	char **buf;
	for (int q=0; i<100000; i++)
	{
		buf = (char**)malloc(blockCount*sizeof(char*));
		for (int i=0; i<size; i++)
		{
			buf[i] = (char*)malloc(blockSize*sizeof(char));
		}
		for (int i=0; i<size; i++)
		{
			free(buf[i]);
		}
		free(buf);
	}
	printf("Hit something...\n");
	printf("Memory freed\n");
	getchar();
	return 0;
}


--Владимир
Total votes 2: ↑1 and ↓10
Полностью согласен с первым комментатором. Статья демонстрирует явное непонимание матчасти. Автору топика могу посоветовать прочитать книгу «Внутренне устройство Windows» Руссиновича. Тогда все вопросы сразу отпадут. Там есть просто замечательный раздел, описывающий диспетчер памяти. В кратце — runtime-библиотека C++ выделяет память большими блоками методом VirtualAlloc, а потом «пилит» эти блоки на мелкие кусочки, при помощи внутренних структур данных, содержащих списки «маленьких» выделенных блоков. На количество зарезервированной памяти вообще смотреть не стоит, по тому что есть механизм подкачки страниц. Обращать внимание нужно только на рабочий набор. C++ аллокатор в праве освобождать зарезервированные VirtualAlloc'ом участки тогда, когда посчитает нужным. Механизм подкачки в праве выгружать страницы тогда, когда посчитает это оптимальным. В общем это сложная система, и проще один раз прочитать раздел книги.
Total votes 1: ↑1 and ↓0+1
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr