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

Question

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

Прежде всего получать что-то подобное/Proc/«PID»/карты, помог бы, но

maintenance info sections 

(как описано здесь: GDB: Listing all mapped memory regions for a crashed process) в GDB не показал мне кучу потребление памяти ,

info proc map 

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

maintenance print statistics 

Вы знаете любую другую команду, которая может быть полезна?

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

Есть ли у вас идеи?

Answer 1

Postmortem отладка такого рода в gdb - это немного больше, чем наука.

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

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

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

Answer 2

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

Answer 3

Если его 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% ================================================ 

но если Ваше письмо таНос wapper затем вы можете сделать свою программу coredump после этого большого количества malloc, чтобы вы могли понять.