Search for memory leak (and analysis) with gdb

Question

My goal is to find out from the main file where the message is located, why a particular process consumes a lot of memory. Is there a summary I can get? As is obvious, there can be no question, because I cannot get access to the process live.

First of all, getting output similar to / proc / "pid" / maps will help, but

maintenance info sections 

(as described here: GDB: listing all the displayed memory areas for a crashed process ) in gdb does not show heap memory consumption.

 info proc map 

is an option, since I can access the machine with the same code, but as far as I saw, this is incorrect. In my process, 700 MB was used, but only about 10 MB were observed on the cards. And I did not see .so-s there that are visible in

 maintenance print statistics 

Do you know any other team that might be useful?

I can always process the code, but it is not easy. Along with reaching all the highlighted data with pointers, it looks like a needle in a haystack.

Do you have any ideas?

Answer 1

Post-mortem debugging of this kind in gdb is a bit more than science.

The most important tool for him, in my opinion, is the ability to write scripts that run inside gdb. The manual will explain this to you. The reason I find this so useful is because it allows you to do something like running data structures and print out the information in them.

Another option for you is to use your version of malloc - write a new malloc function that stores statistics about what is highlighted so you can look at these messages. You can, of course, call the original malloc to do the work of allocating memory.

I'm sorry that I cannot give you an obvious and simple answer that will simply give you an immediate solution - without tools like valgrind, this is very hard work.

Answer 2

If its Linux you do not need to worry about how to make statistics in your malloc. Use a utility called "memusage"

for an example program (sample_mem.c) as shown below

 #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 output will be

 $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% ================================================ 

but if you wrote malloc wapper, then you can make your coredump program after this large amount of malloc so you can get a hint.

Answer 3

Perhaps you can use a simple tool, for example log-malloc.c , which compiles into a shared library that LD_PRELOAD ed before your application and writes all malloc -type functions to a file. At the very least, this can help narrow your search in your dump.