cuitao2046 / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Enhacement: call malloc_stats() when some signal is received #269

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. Use tcmalloc with a program that leaks memory.
2. Given that tcmalloc does not return allocated memory back the kernel 
inmediately after it is done using it, there is no real way using standard 
operating system tools (top, ps..) to see the malloc'd in use memory size of 
the program. This makes it harder for a non-developer to detect memory leaks, 
given that a big memory usage does not necessarily mean that the proccess is 
using that much memory.

What is the expected output? What do you see instead?

It would be nice if tcmalloc could register, or give the option of, a signal, 
which when received would cause tcmalloc to call malloc_stats() (which prints 
malloc statistics to stderr), so that the real memory usage of the process 
could be easily known.

What version of the product are you using? On what operating system?

Perftools 1.6, Debian 5.0 Lenny.

Original issue reported on code.google.com by jsceballos on 22 Sep 2010 at 9:52

GoogleCodeExporter commented 9 years ago
I don't think it's appropriate for libraries (as opposed to binaries) to 
reserve signals, but it wouldn't be hard to add such a signal handler to your 
own binaries.  Alternately, if you suspect a memory leak, you could run with 
flag options that tell tcmalloc to more aggressively give memory back to the 
system.  Or you could run in HEAPCHECKER mode.

In general, my bias is to keep library APIs as small as possible, and given 
there are several ways to achieve this effect, my feeling is it's not necessary 
to add a new function to the library.

Original comment by csilv...@gmail.com on 22 Sep 2010 at 3:51