поиск (и анализ) утечек памяти после смерти с помощью GDB

Question

Моя цель - выяснить из основного файла после смерти, почему определенный процесс потребляет много памяти.Есть ли резюме, которое я могу получить как-нибудь?Как очевидно, о valgrind не может быть и речи, потому что я не могу получить доступ к процессу в реальном времени.

Прежде всего, получение вывода, похожего на / proc / "pid" / maps, может помочь, но1003 *

maintenance info sections

(как описано здесь: GDB: список всех отображенных областей памяти для сбойного процесса ) в gdb не показывал мне потребление памяти в куче.* это вариант, так как я могу получить доступ к машине с точно таким же кодом, но, насколько я видел, это не правильно.Мой процесс использовал 700 МБ, но на просмотр карты приходилось всего около 10 МБ.И я не видел там .so-s, которые видны в

maintenance print statistics

Знаете ли вы какие-либо другие команды, которые могут быть полезны?

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

У вас есть идеи?

Answer 1

Если это Linux, вам не нужно беспокоиться о статистике вашего malloc. Используйте утилиту под названием «memusage»

для примера программы (sample_mem.c), как показано ниже

#include<stdio.h>
#include<stdlib.h>
#include<time.h>

int main(voiid)
{
        int i=1000;
        char *buff=NULL;
        srand(time(NULL));

        while(i--)
        {
                buff = malloc(rand() % 64);
                free(buff);
        }

        return 0;
}

вывод memusage будет

$memusage sample_mem

Memory usage summary: heap total: 31434, heap peak: 63, stack peak: 80
         total calls   total memory   failed calls
 malloc|       1000          31434              0
realloc|          0              0              0  (nomove:0, dec:0, free:0)
 calloc|          0              0              0
   free|       1000          31434
Histogram for block sizes:
    0-15            253  25% ==================================================
   16-31            253  25% ==================================================
   32-47            247  24% ================================================
   48-63            247  24% ================================================

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

Answer 2

Подобная посмертная отладка в gdb - это больше искусство, чем наука.

Самым важным инструментом для этого, на мой взгляд, является возможность писать скрипты, которые запускаются внутри GDB. Руководство объяснит вам это. Причина, по которой я нахожу это настолько полезным, заключается в том, что он позволяет вам выполнять такие действия, как обход структур данных и распечатывать информацию о них.

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

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

Answer 3

Вы можете использовать простой инструмент, такой как log-malloc.c , который компилируется в общую библиотеку, которая LD_PRELOAD редактируется перед вашим приложением, и регистрирует все функции типа malloc вфайл.По крайней мере, это может помочь сузить поиск в вашем дампе.