Утечка памяти в разгружает причины DLL утечку в хост-процессе?
Вы можете использовать этот небольшой фрагмент - добавьте его в functions.php вашей дочерней темы:
function remove_attachments_from_search() {
global $wp_post_types;
$wp_post_types['attachment']->exclude_from_search = true;
}
add_action('init', 'remove_attachments_from_search');
Это исключит тип сообщения вложения из результатов поиска.
Надеюсь, это поможет
6 ответов
Нет, Вы не просачиваетесь.
При смешивании dll моделей (статичный, динамичный) затем, можно закончить с ошибкой памяти при выделении памяти в dll который Вы освобождаете в другом (или освобожденный в exe)
Это означает, что "куча", созданная статически связанным CRT, не является той же "кучей" как CRT другого dll.
Если бы Вы связались с динамической версией CRT, то у Вас была бы утечка, поскольку "куча" совместно используется среди всех динамично связанный CRTs. Это означает, что необходимо всегда разрабатывать приложения, чтобы использовать динамический CRTs или гарантировать, чтобы Вы никогда не управляли памятью через dll границу (т.е. если Вы выделяете память в dll, всегда обеспечивайте стандартную программу для освобождения его в том же dll),
Память, используемая процессом, как прослежено ОС, применима к полному процессу и не характерна для DLL.
Память дана программе в блоках ОС, названной "кучей"
Диспетчеры "кучи" (malloc / новый и т.д.) далее делят блоки, и раздает его к запросу кода.
Только то, когда новая "куча" выделяется, делает ОС, обнаруживают увеличение памяти.
Когда DLL статически связан с библиотекой Времени выполнения C (CRT), частная копия CRT с функциями CRT, которые вызывает код DLL, компилируется и помещается в двоичный файл DLL. Malloc, также включают в это.
Эта частная копия malloc будет вызвана каждый раз, когда подарок кода в статически связанном DLL пытается выделить память.
Следовательно, частная "куча", видимая только к этой копии malloc, получен от ОС этим malloc, и это выделяет память, которую требует код в этой частной "куче".
Когда DLL разгружается, он разгружает свою частную "кучу", и эта утечка остается незамеченной, поскольку вся "куча" возвращается назад к ОС.
Однако, Если DLL динамично связан, память выделяется единственной общей версией malloc, глобального ко всему коду, который связан в общем режиме.
Память, выделенная этим глобальным malloc, выходит из "кучи", которая является также "кучей", используемой для всего другого кода, который связан в динамическом иначе совместно использованный режим и следовательно распространен. Любые утечки от этой "кучи" поэтому становятся утечкой, которая влияет на целый процесс.
Редактирование - Добавленные описания связывающегося сценария.
Вы не можете сказать. Это зависит от реализации Вашего статического и динамического CRT. Это может даже зависеть от размера выделения, поскольку существуют CRTs, которые передают большие выделения ОС, но реализуют их собственную "кучу" для маленьких выделений.
Проблема с CRT, который утечки, конечно, что она протекает. Проблема с CRT, который не протекает, состоит в том, что исполняемый файл мог бы разумный ожидать использовать память, поскольку malloc'ed память должен остаться применимым, пока свободный не назван.
От ошибок потенциала MSDN передающие объекты CRT через границы DLL
Каждая копия библиотеки CRT имеет отдельное и отличное состояние. По сути, объекты CRT, такие как дескрипторы файлов, переменные среды и локали только доступны для копии CRT, где эти объекты выделяются или устанавливаются. Когда DLL и его пользователи используют различные копии библиотеки CRT, Вы не можете передать эти объекты CRT через границу DLL и ожидать, что они будут взяты правильно с другой стороны.
Кроме того, потому что каждая копия библиотеки CRT имеет свой собственный диспетчер "кучи", выделение памяти в одной библиотеке CRT и передача указателя через границу DLL, которая будет освобождена другой копией библиотеки CRT, являются потенциальной причиной для повреждения "кучи".
Надеюсь, это поможет.
Можно было сделать тест и видеть, существуют ли утечки памяти. Вы запускаете простой тест, 30 раз выделяя 1 МБ каждый раз. Необходимо понять это вполне быстро.
Одна вещь наверняка. При выделении памяти в DLL, необходимо также освободить ту память там (в DLL).
Например, у Вас должно быть что-то вроде этого (простой кроме интуитивного псевдокода):
dll = DllLoad();
ptr = dll->alloc();
dll->free(ptr);
DllUnload(dll);
Это должно быть сделано, потому что DLL имеет другую "кучу", чем исходный процесс (который загружает dll).
На самом деле, отмеченный ответ неверен. Это как раз и есть утечка. Хотя технически возможно для каждой dll реализовать свою собственную кучу и освобождать ее при выключении, большинство "runtime" куч - статических или динамических - являются обертками вокруг API кучи процесса Win32.
Если не позаботиться о том, чтобы гарантировать, что это не так, dll будет сливать информацию о распределении за цикл load, do, unload.