C++: крошечная утечка памяти с помощью std::map

«{290}» в отчете об утечке — это порядковый номер выделения памяти для блока памяти, в котором произошла утечка. Если этот порядковый номер всегда один и тот же, вы можете использовать _crtBreakAlloc, чтобы вызвать перерыв в отладчике при достижении этого порядкового номера выделения. Из трассировки стека вы можете узнать, где выделяется этот блок. Когда вы знаете, где и для какой цели он выделяется, довольно легко определить, почему он не освобождается.

Прочтите документацию по отладочной куче, чтобы узнать о _crtBreakAlloc.

Уточним одну вещь: в std::map нет утечки. Код доступен для просмотра каждому разработчику, и он уже был бы обнаружен.

Если вы правы, я полагаю, что утечка связана с копированием classDef или анонимного объекта FastStr. Но без кода для обоих это слишком сложно сказать. Вы говорите, что они оба являются указателями, что заставляет меня поверить, что рассматриваемая строка является просто симптомом, а не реальной проблемой. Как насчет того, чтобы показать код?

OldFart предоставил окончательное решение проблемы.

Утечек памяти изначально не было. Ячейки памяти, предложенные отладчиком, были в файле STL xmemory, строка 43 :

return ((_Ty _FARQ *)::operator new(_Count * sizeof (_Ty)));

Но это были не настоящие утечки памяти, а просто переусердствовавший отладчик VC++2008. Я протестировал PurifyPlus (eval.version) и предположил, что в моей программе нет утечек памяти. Итак, эти 16 байт удаляются при выходе из программы, хотя да, не очень хорошо, что STL не делает этого раньше.

Так что еще раз, спасибо всем за ваши ответы, во-первых, никогда не было проблем!

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

До сих пор мы не видели ни одной строки вашего кода, поэтому мы практически не можем сказать что-то большее, чем «во всех широко используемых реализациях STL std::map не происходит утечка памяти, при любых обстоятельствах." После запуска деструктора карты вся память освобождается.

Конечно, если вы используете какую-то непонятную проприетарную реализацию STL, все ставки сняты, но в остальном карта не виновата.

Конечно, если вы подозреваете map в утечке памяти, сделайте это. Это код только в заголовке, поэтому он виден и может быть отлажен так же, как и ваш собственный код. Пройдитесь по нему в отладчике, посмотрите, какие выделения он делает и освобождаются ли они снова.

Но, скорее всего, проблема в FastStr или... в чем-то еще в вашем коде.

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

Не запускайте полную программу с самого начала. Если вы уверены, что проблема в строке, которую вы разместили, то вы можете пропустить весь первоначальный анализ, что исключит множество возможностей. Точно так же удалите все, что происходит после этого. Если это не воспроизводит ошибку, значит, проблема не в выделенной вами строке.

И когда вы получите небольшой образец, который воспроизводит ошибку, у вас также будет что-то, что вы можете опубликовать здесь, чтобы мы могли просмотреть.

Если вы поместите какую-либо карту в область файлов в DLL, MS Visual Studio 2008 будет жаловаться на утечку памяти. Вам не нужно ничего делать с картой, просто объявите ее:

фунт-включить ‹карта›

использование пространства имен std;

карта ‹ короткая, длинная › test_map;

...

Обнаружены утечки памяти! Сброс объектов -> нормальный блок {143} по адресу 0x00037140, длина 24 байта. Данные: ‹@q @q @q > 40 71 03 00 40 71 03 00 40 71 03 00 CD CD CD CD Дамп объекта завершен.

Не происходит в основной программе; не происходит, если карта находится в области действия функции. Вероятно, это ложно: карта освобождается после прекращения обнаружения утечки памяти.

просто чтобы подтвердить, что статическая карта, расположенная в области файлов в DLL, создает ту же самую ситуацию с крошечной утечкой памяти (с использованием MS Visual Studio 2008).

Моя интуиция в этом вопросе заключалась в том, чтобы взглянуть на FastStr. Вы говорите, что это простая оболочка char*, но как она справляется с копированием (т. е. копируется или воссоздается внутренний char*)? Можете ли вы показать нам код для FastStr, пожалуйста?

Кроме того, ваши доказательства, как указано, предполагают некоторые статические данные или если упомянутый вами «парсер» создан только один в ваших блоках тестового кода, то член объекта «парсер» является вероятным источником утечки памяти.

Другим предложением было бы запустить ваш код под более описательным инструментом, таким как valgrind, чтобы точно определить утечку? Valgrind (или Purify) сообщит вам точное место утечки памяти в коде.

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

Можно ли запустить этот код под Linux, используя «valgrind --leak-check»? Если это так, valgrind может показать вам, какая память утекает.