Проверка на утечки памяти в работающей программе

Question

У меня есть вопрос из любопытства, касающийся проверки на утечки памяти.

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

Итак, в свете этого я подумал, что если у вас есть долго работающая программа, которая malloc() прерывисто и не free(), пока приложение не завершится, то потенциал для использования памяти (не обязательно до утечки ) огромны и не наблюдаются при использовании этих инструментов, потому что они проверяют только после времени жизни программ. Существуют ли GDB-подобные инструменты, которые могут останавливать приложение во время работы и проверять наличие памяти, которая есть и не указана в экземпляре в жизни приложения?

Answer 1

Существуют ли GDB-подобные инструменты, которые могут останавливать приложение во время работы и проверять наличие памяти, на которую нет ссылки в экземпляре в жизни приложения?

Да: Вальгринд.

В частности, SVN-версия Valgrind имеет встроенную заглушку gdbserver.

Это позволяет вам выполнять все виды классной отладки, что было невозможно до:

• Вы можете запускать программу под valgrind и одновременно иметь точки останова GDB
• Вы можете спросить Вальгринда: выделена ли эта память? была ли эта переменная инициализирована?
• Вы можете спросить Вальгринда: какие новые утечки произошли с тех пор, как я в последний раз просил утечки?

Я думаю, вы также можете попросить его перечислить не просочившиеся новые выделения.

Answer 2

То, что я сделал, что не было инструментом для долго работающего сервера на основе сокетов, - это сделать операцию, но перед этим распечатать объем свободной памяти, затем распечатать ее после моей операции, ипосмотрим, есть ли какая-либо разница.

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

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

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

Answer 3

Это обычно невозможно в языке, который поддерживает арифметику указателей, поскольку, например, вы можете привести указатель к целому числу и обратно. Смотри http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BitOp/pointer.html

Answer 4

Утечка памяти определяется как память, на которую ничего не ссылается в программе.

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

Однако, если вы распределили память, никогда не освобождали ее, но у вас нет указателя, указывающего на нее, вы, скорее всего, вытекли из этой памяти - поскольку у вас нет способа сослаться на нее.

Такие программы, как valgrind, могут обнаруживать утечки описанного выше типа (потеря ссылки). AFAIK ничто не может найти «логические» утечки, где вы все еще держите ссылку на память.