Почему удаленная память недоступна для использования?C ++ - PullRequest
1 голос
/ 23 марта 2011

У меня есть 200 МБ XML-файл, который я загружаю с использованием TinyXML . Моя проблема в том, что когда объект TinyXML уничтожен, используемая им память не будет использоваться повторно. Я использовал детектор утечки памяти, который использовал в других проектах, и вручную прошел через код и не смог обнаружить утечек памяти, поэтому я не подозреваю, что проблема связана с утечкой памяти.

Этот код воспроизведет проблему:

#include <iostream>
#include <tinyxml.h>

int main()
{
    char* filename = "../LargeFile.xml";

    {
        TiXmlDocument targetDoc( filename );
        targetDoc.LoadFile();
    }

    char* buf = new char[ 524288000 ];
    delete [] buf;

    return 0;
}

Использование монитора адресного пространства Я вижу, что после LoadFile() появляется большой кусок красного, затем после уничтожения targetDoc все становится желтым. Затем, когда выделяется последний символ, он отображается красным, но поверх зеленой зоны, а не желтой, освобожденной от TinyXML. Если попытаться выделить больше буферов, чем имеется зеленое адресное пространство, произойдет сбой приложения (нехватка памяти). Это можно увидеть на изображениях ниже.

After Load After Unload Char Buffer Allocation

В соответствии со страницей монитора адресного пространства «Свободное адресное пространство показано зеленым, зарезервированные адреса - желтым, а используемые (выделенные) области памяти красным» Так почему же память, освобождаемая TinyXML, остается «зарезервировано» в соответствии с адресным пространственным монитором. Что может вызвать это, и как я могу остановить это?

РЕДАКТИРОВАТЬ:

«Вы выделяете большие буферы? Если это так, то может быть фрагментация памяти в желтом пространстве, и нигде не может быть выделен большой непрерывный буфер»

Хороший вопрос, однако, это указывает на то, что в TinyXML есть утечка памяти, и ни один из моих инструментов не показал, что она есть.

UPDATE

Я сделал цикл, который бесконечно распределял целые, которые в итоге, казалось, использовали все желтое пространство. Однако большие выделения не используют его. Это указывало на то, что были небольшие утечки, которые засорялись в куче во время анализа xml-файла с помощью tinyXML, который фрагментирует кучу таким образом, что только объекты, достаточно маленькие, чтобы поместиться между утечками, могли быть выделены в желтом пространстве. , Поэтому я искал все больше и больше утечек в TinyXML и до сих пор не нашел никаких. Кажется, что все освобождается правильно, что возвращает меня в исходное состояние растерянности.

Я затрудняюсь объяснить проблему.

Char Buffer Allocation Char Buffer Allocation2 Char Buffer Allocation3

Ответы [ 2 ]

6 голосов
/ 23 марта 2011

Вы действительно видите какие-либо другие признаки проблем с памятью? Зарезервированная память указывает, что диапазон адресов зарезервирован от ОС, но фактически не используется физическая память. Не о чем беспокоиться. Когда вам в следующий раз понадобится память, она сначала выйдет из этого зарезервированного пространства.

4 голосов
/ 23 марта 2011

Большинство ОС фактически не высвобождают память обратно в ОС, когда выполняется free () (Linux иногда делает это для больших выделений).Вместо этого приложения используют функцию OS Sbreak () для увеличения памяти, поддерживая «высокую отметку».Пока вы выполняете free () для каждого malloc (), память не просачивается, и будущие выделения будут поступать из той же памяти.Конечно, может случиться так, что что-то внутри TinyXML не делает такое сопоставление освобождает, намеренно или иным образом, например:

  • некоторая функция в классе TinyXML или вызванная им, может иметь статическую переменную локального указателяинициализируется так, чтобы указывать на вновь выделенную кучу при первом вызове функции.Если это произойдет после того, как другие подпрограммы выделят много памяти для более временных данных, то даже после освобождения последней памяти выделение статического указателя может вызвать некоторую фрагментацию, предотвращая выделение огромного непрерывного блока в освобожденном пространстве.
...