Три вида утечек памяти

[picul]

Три вида утечек в памяти

Обычно говорят «утечек памяти», без «в».

[qw1]

N single-threaded workers = N однопоточных работников?
Переводчик точно в теме, о чём текст?

[gecube]

Согласен.

Мы каждую секунду выводим состояние памяти с точки зрения операционной системы и с точки зрения собственного сборщика мусора Python.

Каждую секунду? Переводчик, вы там как? Код противоречит текстовому описанию.

[AEP]

И еще «дамп ядра», когда имеется в виду «core dump».

[LAutour]

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

[svr_91]

Можно, но осторожно :)
Вызов free должен быть в той же единице трансляции (по простому, cpp-файле), что и вызов malloc
Например, можно создать дополнительную функцию

char * leak_memory() {
  char *leaked = malloc(4096);
  use_a_buffer(leaked);
  return leaked;
}
void freeMemory(char *mem) {
 free(mem);
}

[qw1]

Вызов free должен быть в той же единице трансляции (по простому, cpp-файле)

Это ещё почему? Все obj-файлы линкуются с одним libc, и free из любой единицы трансляции вызовет тот же free.

[Siemargl]

Это так в случае статической линковки. В случае же динамической — может не выполняться.
Потому переданный через границы DLL/SO указатель, надо освобождать функцией из этой же DLL

[qw1]

Верно, но в единицам трансляции это не имеет отношения.

[svr_91]

Да, возможно я погорячился насчет той же единицы трансляции. Скорее тут стоило бы сказать «в той же DLL». Но от моего совета вряд ли будет хуже

[qw1]

Можно уточнить до «того же экземпляра рантайма». Потому как если все DLL динамически слинкованы с некоей msvcrt.dll, то тоже можно выделять память в одной DLL и освобождать в другой. В Delphi для этого есть packages.

Но от моего совета вряд ли будет хуже

Создание мифов — да, безобидное дело )))

[Siemargl]

тоже неточно. может оказаться, что разными модулями используются разные версии msvcrt.dll, что также приведет к разным хипам

нужно именно до «того же экземпляра рантайма»

[kuraga333]

В продолжение темы утечки типа 3: sourceware.org/bugzilla/show_bug.cgi?id=14827.

В Glibc, при free участка памяти размером меньше M_MXFAST (константа времени компиляции), освобожденный участок не возвращается в пользование ОС. Пока malloc_trim не вызовешь, все эти кусочки, сколько бы их ни было, «занимают место»…

До того, как я встретил это при работе с большой таблицей в Pandas (Python), к своему стыду, не задумывался, что «free dynamic memory» не включает, вообще говоря, «release free memory».

Вообще, ненастраиваемость этой и связанных констант, а также ее дефолтное значение, считал неправильностью (особенно понимая, что это может быть причиной «у меня течет KDE/Chrome/etc. ну и, точно, моего кода на Pandas), но, благо, мне объяснили, что никто (free) в этом мире ничего никому не должен.

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