В некоторых программах часть выделенной памяти вообще не уничтожается, но они требуются на протяжении всего времени выполнения программы. Следовательно, в целом считается безопасным.
Но есть и другие объекты, которые не предназначены для всего времени выполнения программы, но не уничтожены из-за промахов разработчика. Это фактические утечки памяти, которые следует устранить.
Когда мы запускаем следующую команду Valgrind, она отображает только общие утечки после завершения выполнения программы. Следовательно, кто-то может прояснить, как отличить вышеупомянутые два сценария от результатов проверки утечки Valgrind.
Команда, которую я использовал для обнаружения утечек памяти;
valgrind --log-file=valgrind_output.txt --tool=memcheck --leak-check=yes ./MyTestProgram
Типичный вывод в конце исполнения;
==10108== LEAK SUMMARY:
==10108== definitely lost: 392,323 bytes in 1,164 blocks
==10108== indirectly lost: 178,120 bytes in 4,283 blocks
==10108== possibly lost: 170,155,118 bytes in 3,347,087 blocks
==10108== still reachable: 263,778,326 bytes in 3,935,669 blocks
Есть ли в Valgrind такая функция, как Tap в инструменте IBM Purify, которая может обнаруживать утечку памяти во время выполнения?
Вы можете использовать 2 различных метода для поиска утечек во время выполнения.
Из команды оболочки запустите
vgdb leak_check
Существуют и другие необязательные аргументы для команд монитора leak_check, например, в
найти доступную память, или просто память, которая увеличилась или ….
Подробности смотрите в руководстве пользователя valgrind:
http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
Внутри вашей программы:
Вы можете добавить в свою программу клиентские запросы для поиска утечек.
Например. вставить «вызовы» в VALGRIND_DO_LEAK_CHECK или VALGRIND_DO_ADDED_LEAK_CHECK
Увидеть
http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs
Больше подробностей
Есть ли в Valgrind такая функция, как Tap в инструменте IBM Purify, которая может обнаруживать утечку памяти во время выполнения?
Нет, нет Valgrind не может знать, есть ли утечка, если программа не закончила, потому что он не может знать, что будет выпущено, когда программа закончится.
Вы можете преднамеренно завершить работу вашей программы во время выполнения, чтобы убедиться, что вы можете проверить выделенную память в этот момент. Вы можете сделать это, добавив обработчик сигнала для некоторого пользовательского сигнала, такого как SIGUSR1.
signal(SIGUSR1, myhandler);
в вашем обработчике вы делаете что-то вроде этого:
printf("debug exit!\n");
int *ptr = 0;
*ptr = 0xdeadbeef;
Затем вы можете отправить этот сигнал вашему приложению следующим образом:
kill -s SIGUSR1 `ps -aux| grep myapp | head -n -1 | awk '{print $2}'`
Затем вы можете проверить различия в количестве выделенных объектов. Если вы знаете, что числа должны оставаться одинаковыми, или если какое-то число продолжает расти, вы можете проверить место, где это происходит, и посмотреть, есть ли там утечка памяти.