Как найти утечку памяти запущенного процесса?

Как найти утечку памяти запущенного процесса?

Есть ли способ найти утечку памяти запущенного процесса? Я могу использовать Valgrind для поиска утечек памяти до начала процесса. Я могу использовать GDB для присоединения его к запущенному процессу. Как я могу отладить утечку памяти запущенного процесса?

решение1

Вот шаги, которые почти гарантированно найдут причину утечки памяти:

  1. Узнайте PID процесса, вызывающего утечку памяти.

    ps -aux
    
  2. захватить /proc/PID/smapsи сохранить в файл, например BeforeMemInc.txt.

  3. подожди пока память увеличится.
  4. захватить снова /proc/PID/smapsи сохранить егоafterMemInc.txt
  5. найдите разницу между первым smapsи вторым smaps, например, с помощью

    diff -u beforeMemInc.txt afterMemInc.txt

  6. Запишите диапазон адресов, где увеличился объем памяти, например:

       beforeMemInc.txt            afterMemInc.txt
    ---------------------------------------------------
    2b3289290000-2b3289343000   2b3289290000-2b3289343000  #ADDRESS
    Shared_Clean:    0 kB       Shared_Clean:    0 kB          
    Shared_Dirty:    0 kB       Shared_Dirty:    0 kB
    Private_Clean:   0 kB       Private_Clean:   0 kB
    Private_Dirty:  28 kB       Private_Dirty:  36 kB  
    Referenced:     28 kB       Referenced:     36 kB
    Anonymous:      28 kB       Anonymous:      36 kB  #INCREASE MEM
    AnonHugePages:   0 kB       AnonHugePages:   0 kB
    Swap:            0 kB       Swap:            0 kB
    KernelPageSize:  4 kB       KernelPageSize:  4 kB
    MMUPageSize:     4 kB       MMUPageSize:     4 kB
    Locked:          0 kB       Locked:          0 kB
    VmFlags: rd wr mr mw me ac  VmFlags: rd wr mr mw me ac
    
  7. используйте GDB для дампа памяти запущенного процесса или получите дамп памяти с помощьюgcore -o process

  8. Я использовал gdb для запущенного процесса, чтобы выгрузить память в какой-то файл.

    gdb -p PID
    dump memory ./dump_outputfile.dump 0x2b3289290000 0x2b3289343000
    
  9. теперь используйте stringsкоманду или hexdump -Cдля печатиdump_outputfile.dump

    strings outputfile.dump
    
  10. Вы получаете удобочитаемую форму, в которой вы можете найти эти строки в своем исходном коде.

  11. Проанализируйте свой источник, чтобы найти утечку.

решение2

Я думаюмемлиаксименно то, что вам нужно.

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

Работает на GNU/Linux и FreeBSD.

ПРИМЕЧАНИЕ:Я автор, любые предложения приветствуются.

== ИЗМЕНИТЬ ==

Я также написал еще один инструментлипкий, который подключает функции памяти с помощью LD_PRELOAD.

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

Значительно меньшее влияние на производительность, поскольку нет помех сигнала.

По сравнению с аналогичными инструментами (например, mtrace), он выводит полный стек вызовов в точке подозрительной утечки памяти.

решение3

В Linux вы можете включитьmtraceв вашей программе, но это изменение кода.

В OpenBSD вы можете попробоватьстатистика malloc.

Google'sпроверка на герметичностьтакже может быть полезным, и в отличие от mtrace вы сможете использовать его, LD_PRELOADчтобы избежать перекомпиляции.

решение4

IBM'sОчищатьвероятно, самый старый и самый сложный инструмент из всех. Он помечает номер строки в коде, который вызывает утечку памяти.

Связанный контент