Как определить утечку памяти linux
Обновлено: 04.07.2024
Сначала я искал существующие ответы и увидел, что Valgrind это любимый инструмент отладки утечек памяти в Linux. к несчастью Valgrind не похоже на работу для моих целей. Я постараюсь объяснить, почему.
- Утечка воспроизводится только в среде заказчика. Из-за определенных
юридические ограничения, мы должны работать с существующим бинарным. Нет перестраивает. - В обычной среде наше приложение потребляет
Что мне нужно, это эквивалент Microsoft UMDH: включить трассировку стека для каждого распределения кучи, затем в определенный момент времени сбросить все распределения, сгруппированные по стекам и упорядоченные по количеству распределений в порядке убывания. Наше приложение поставляется на платформах Windows и Linux, поэтому я знаю, что производительность в Windows ниже UMDH все еще терпимо.
Вот инструменты / методы, которые я рассмотрел
Я что-то пропустил? Есть ли легкий Valgrind варианты или существующий инструмент LD_PRELOAD?
Решение
GNU libc имеет встроенную отладку malloc:
Используйте LD_PRELOAD для вызова mtrace() из вашего собственного .so:
Скомпилируйте это с:
Запустите это с:
Позже осмотрите выходной файл:
И вы получите что-то вроде:
Конечно, не стесняйтесь писать свои собственные ловушки malloc, которые выводят весь стек (вызывая трассировка () если вы думаете, что это поможет).
Номера строк и / или имена функций будут доступны, если вы где-то сохранили отладочную информацию для двоичного файла (например, в двоичном файле есть некоторая встроенная отладочная информация, или вы это сделали objcopy --only-keep-debug my-leaky-program my-leaky-program.debug ).
Кроме того, вы можете попробовать GC Boehm, он также работает как детектор утечки:
Другие решения
По сравнению с вашим инструментом heapwatch производительность должна быть намного лучше, так как я использую libunwind и более позднюю libbacktrace для задержки аннотации backtrace с отладочной информацией DWARF.
Я хотел бы получить больше отзывов об этом, так что попробуйте!
MemoryScape будет соответствовать вашим потребностям. Это инструмент отладки динамической памяти, который поставляется с TotalView отладчик.
memleax должен работать на вас.
Он отлаживает утечку памяти запущенного процесса, присоединяя его, без перекомпиляции программы или перезапуска целевого процесса. Это очень удобно и подходит для производственной среды.
Он TRAP только для вызовов malloc / free (), поэтому он должен оказывать меньшее влияние на производительность, чем Vagrild.
Работает на GNU / Linux-x86_64 и FreeBSD-amd64.
ПРИМЕЧАНИЕ: я автор, любое предложение приветствуется
Да, MemoryScape может группировать выделения по расположению в стеке.
Удалось ли вам получить ознакомительную версию? Предполагая, что вы использовали адрес электронной почты, который не похож на бота, вы должны были довольно быстро получить от нас ответ. Если нет, или если у вас возникли технические проблемы, свяжитесь с нашей службой технической поддержки.
Главный менеджер по продукту для TotalView в Rogue Wave Software
электронная почта: Имя. Фамилия (в) roguewave. ком
Удивительно, но я не смог найти ничего подобного UMDH от Microsoft в домене с открытым исходным кодом или доступном для немедленной загрузки. (Я также посмотрел на Google Heap Leak Checker но это больше похоже на Valgrind, а не на UMDH). Так что я закончил писать инструмент сам, используя инструменты Malloc Проект в качестве ориентира:
У инструмента есть ряд ограничений, но он отлично работал для моих целей.
сначала я искал существующие ответы и увидел, что отчет является любимым инструментом для отладки утечки памяти в linux. К сожалению отчет Кажется, не работает для моих целей. Я попытаюсь объяснить почему.
- утечка воспроизводит только в окружающей среде клиента. Из-за некоторых правовые ограничения мы должны работать с существующими двоичными. Никаких перестроек.
- в регулярной окружающей среде наша приложение потребляет
Мне нужен эквивалент Microsoft umdh очередь: включите трассировку стека для каждого распределения кучи, затем в определенный момент времени сбросьте все распределения, сгруппированные по стекам и упорядоченные по количеству распределения в порядке убывания. Наш приложение поставляется на платформах Windows и Linux, поэтому я знаю, что производительность в Windows под umdh очередь - это еще терпимо.
вот инструменты / методы, которые я рассмотрел
- отчет ' s -memcheck и массив инструменты они делают гораздо больше, чем нужно (например, сканирование всей памяти процесса для каждого выделения pointer), они слишком медленные, и они все еще не делают именно то, что я
need (dump callstacks отсортированы по графы), поэтому мне придется написать некоторые скрипты разбора вывода - dmalloc библиотека (dmalloc.com) требуется новый binary
- LeakTracer (http://www.andreasen.org/LeakTracer/) работает только с c/" >C++ новый/удалить (мне нужно аналог также), не имеет group-by-stack и сортировать функциональность
- реализация инструмента себя как .Итак, библиотека с использованием LD_PRELOAD механизм (переопределение 'malloc' использование механизма LD_PRELOAD) Это займет по крайней мере неделю, учитывая мои навыки кодирования для Linux, и он чувствует как изобретение велосипеда.
Я что-нибудь пропустил? Есть ли легкий отчет параметры или существующий инструмент LD_PRELOAD?
Как определить, есть ли утечка памяти в программе под Linux?
Язык C - это язык, которого никогда нельзя избежать при разработке встраиваемых систем. Будь то операционная система или разработка с нуля, эффективность языка C проявляется повсюду.Язык C может напрямую управлять памятью и имеет идеальный механизм управления памятью. Если вы используете его хорошо, вы можете резать железо, как грязь, а если вы не используете его хорошо, вы можете порезать себе руки!
Будь то C или C ++, многие студенты неизбежно совершают ошибку утечки памяти. Поскольку мы обычно пишем небольшие программы, даже если запрошенная память не высвобождается, это не повлияет на результаты программы, поэтому мы редко обращаем внимание на утечки памяти. Но если поставить эту проблему в коммерческий проект, это будет большой скрытой опасностью.
Как определить, есть ли в программе утечка памяти, сегодня я поделюсь с вами общим инструментом -valgrind。
valgrind Его можно назвать артефактом отладки памяти Linux, вы можете использовать его для обнаружения утечек памяти, диких указателей или проверки вызовов функций, кешей и проблем использования стека. Первый взглядvalgrind Руководство для мужчин:
Его основные функции помещены в параметр [–tool =].
memcheck: это наиболее широко используемый инструмент valgrind. Это тяжелая программа проверки памяти, которая может найти большинство ошибок памяти при разработке, таких как: использование неинициализированной памяти, использование памяти, которая была освобождена, доступ к памяти за пределами границ и т. д. .
callgrind: в основном используется для проверки проблем в процессе вызова функции в программе.
cachegrind: в основном используется для проверки проблем с использованием кеша в программе.
helgrind: в основном используется для проверки проблем конкуренции в многопоточных программах.
massif: в основном используется для проверки проблем с использованием стека в программе.
extension: вы можете использовать функции, предоставляемые ядром, для написания ваших собственных специальных инструментов отладки памяти.
Неинициализированный указатель
test1.c
Лучше всего добавить параметр [-g] при компиляции. Параметр [-g] может видеть номер строки при отладке.
Проходитьvalgrind Отладчик.
Отладочная информация ясно говорит нам, что существует проблема с 7-й строкой программы: 1. Используется неинициализированный указатель; 2. Незаконный доступ к указателю. Вызвать segfault в конце программы.
Утечка памяти
test2.c
Добавьте [–leak-check = full] для повторного запуска:
На этот раз было четко указано, что в строке 7 программы произошла утечка памяти, и память была запрошена, но в итоге она не была освобождена.
Использовать дикий указатель
test3.c
результат операции:
Хотя в программе используются "дикие" указатели, во время работы не возникает ошибок сегментации. Здесь управление памятью языка C не является строгим.Ошибка сегментации возникает только при доступе к памяти, защищенной системой.Хотя память освобождена, она не защищена, поэтому даже при обращении к ней проблем не возникнет. Однако valgrind все еще может обнаружить это незаконное использование.
Стек за пределами доступа
test4.c
результат операции:
Освободите память несколько раз
test5.c
новый и удалить
valgrind То же самое относится к программам на C ++. Например, команды new и delete не совпадают, и доступ к стековой памяти осуществляется вне пределов. Использование такое же, как и выше, поэтому здесь код не пишется.
подводить итоги
При обнаружении проблемы трудно обнаружить проблему утечки памяти, поэтому в настоящее время valgrind может проявить большую мощность.В то же время я также хочу напомнить всем, что вам также следует уделять внимание при написании кодов. После того, как вы подадите заявку на память, вы должны освободить ее. Так же, как пойти в библиотеку, чтобы взять книгу, библиотека рано или поздно закроется. Развивайте хорошие навыки программирования, ведь отладка программ - пустая трата времени.
Больше статей, видео, встроенных обучающих ресурсов, подпишитесь на WeChat【Интеллектуальное оборудование Xueyide】
Есть встраиваемая система на базе x86 и в ней OpenEmbedded крутится. Со временем, в течение часа, потребление памяти системой возрастает на 10 Мб, и так всё время, видимо до исчерпания.
Есть ли какой-то способ выявить процессы в системе, потребление памяти которыми (не обращая внимания на периодические колебания) имеет тенденцию к увеличению?
Кто как решает эту проблему?
Всякими профилировщиками для поиска утечек памяти относительно единичной программы своей разработки пользоваться умею, а вот как с системой поступить?
Первое, что приходит в голову - собирать скриптом выхлоп
и потом распарсить.
Объем занятой памяти. Он растет, потом ее не хватит. Свопа в системе нет, да и он не безграничен.
Я _не_знаю_ что заняло память. Просто свободной памяти становится меньше и это не дисковое кэширование. Просто что-то течет.
Спасибо, интересный метод, надо попробовать.
atop еще умеет статистику собирать.
1. Растут ли процессы? От этого зависит, в ядре искать или в юзерспейсе.
2. Фейлят ли попытки выделить память? Если нет, то память занимается под кэш и в этом ничего страшного нет.
3. Есть ли в ядре самописаные драйверы? Если есть, можно посмотреть /proc/slabinfo - в зависимости от тактики выделения памяти в драйвере, утечка может быть заметна там.
1. это еще надо выяснить - растет общий объем используемой памяти 2. про кэш в курсе, он тут ни при чем 3. нет
Спасибо, попробую atop, не слышал про эту штуку ранее.
1. это еще надо выяснить - растет общий объем используемой памяти
Чудес не бывает - память либо в процессах, либо в кэше, либо в слабах.
2. про кэш в курсе, он тут ни при чем
Отказы в выделении памяти есть или нет?
- Кэш ядра имеет тенденцию съедать всю доступную память
- Проверить не возвращается ли память после вызова
Вангую зелененький блоб втихую жрет.
Вангую зелененький блоб втихую жрет
Пока не занимался этой задачей. Короче, я использую утилиту htop, она показывает что кэш (дисковый в том числе), а что просто занятая память. И я вижу что в течение часа память кушается всё больше и больше. Попробую покилять свои программы, drop_caches тоже попробую.
Гдето на просторах интернетов есть перловый скрипт который это делает для приложений путем периодического парсинга /proc. Кажется он один такой.
Спасибо за наводку, попробую его поискать.
Как ты узнаешь, что потребление памяти растёт?
Оставлю на сутки и посмотрю сколько сожрало. Это когда всё доделаю.
Понял. htop Mem: used: - это used растет, медленно растет, что-то течет.
I-Love-Microsoft ★★★★★ ( 04.09.15 14:29:46 )Последнее исправление: I-Love-Microsoft 04.09.15 14:31:02 (всего исправлений: 1)
Какой-то процесс в htop становится безусловным лидером по потреблению памяти? Плодятся ли новые процессы? Если да, то какие?
Ты перепутал с амд.
На рабочем компьютере я вижу что память очень прыгает, но если ничего не делать и смотреть htop то видно что нет тенденции к росту, утечек нет. На целевой же системе ПО, написанное коллегами, видимо что-то не чистит за собой, но! Их ПО это не просто софт на Qt но еще и набор скриптов, может стороннее ПО дает эффект.
Чисто визуально процент потребленной памяти процессами не растет. Лидеры по потреблению тоже не увеличивают процент. Новые процессы не плодятся - есть общий счетчик процессов и он не растет (была ошибка что плодились процессы и я ее пофиксил).
В общем, буду пробовать этот совет выше:
Гдето на просторах интернетов есть перловый скрипт который это делает для приложений путем периодического парсинга /proc. Кажется он один такой.
Читайте также: