Yes, there is a four-byte memory leak. Although you can see that the pointer p has not been released when you look at the code, what you need to master here is how to use the tcmalloc tool to analyze the problem when you cannot intuitively find the memory leak point by reading th

Download and install tcmalloc

#1, go to google download code:

Of course, you'd better download the latest or most stable version, here for example, download version 2.1:

wget https://gperftools.googlecode.com/files/gperftools-2.1.tar.gz

#Decompress

tar -zxvf google-perftools-2.1.tar.gz

#Look at the instructions

cd google-perftools-2.1

./configure -h

./configure

make && make install

code to replace malloc

in code How do we use tcmalloc to replace malloc

glibc?

When linking tcmalloc, we can use any of the following methods:

1. Before starting the program, pre-load the environment variable settings of the tcmalloc dynamic library: exportLD_PRELOAD="/usr/local/lib/libtcmalloc.so"

2. Add to the place where your dynamic library links: -ltcmalloc

detects memory leaks

Test code 1:

#include iostreamusing namespace std;int main(){int *p = new int();return 0;}

Compilation: g++ t.cpp -o main -ltcmalloc -g -O0

Memory leak check: env HEAPCHECK=normal ./main

Result:

root@ubuntu:/home/gaoke/test# env HEAPCHECK=normal ./mainWARNING: Perftools heap leak checker is active -- Performance may sufferHave memory regions w/o callers: might report false leaksLeak check _main_ detected leaks of 4 bytes in 1 objectsThe 1 largest leaks:*** WARNING: Cannot convert addresses to symbols in output below.*** Reason: Cannot find 'pprof' (is PPROF_PATH set correctly?)*** If you cannot fix this, try running pprof directly.Leak of 4 bytes in 1 objects allocated from:@ 4007ef @ 7f7895a64f45 @ 400719 If the preceding stack traces are not enough to find the leaks, try running THIS shell command:pprof ./main "/tmp/main.6712._main_-end.heap" --inuse_objects --lines --heapcheck--edgefraction=1e-10 --nodefraction=1e-10 --gvIf you are still puzzled about why the leaks are there, try rerunning this program with HEAP_CHECK_TEST_POINTER_ALIGNMENT=1 and/or with HEAP_CHECK_MAX_POINTER_OFFSET=-1If the leak report occurs in a small fraction of runs, try running with TCMALLOC_MAX_FREE_QUEUE_SIZE of few hundred MB or with TCMALLOC_RECLAIM_MEMORY=false, it might help find leaks more repeatedlyExiting with error code (instead of crashing) because of whole-program memory leaks

Please note that there is the keyword Leak here, so you have to be careful of the possible memory leak here. It is prompted that

Leak of 4 bytes in 1 objects allocated from

pair has a four-byte memory leak. Although you can see that the pointer p has not been released when you can't intuitively find the memory leak point by reading the code, what you need to know here is how to use the tcmalloc tool to analyze the problem when you cannot intuitively find the memory leak point by reading the code.

I believe that if you are careful, you will notice the line of output running

pprof ./main "/tmp/main.6712._main_-end.heap" --inuse_objects --lines --heapcheck --edgefraction=1e-10 --nodefraction=1e-10 --gv

Here is the pprof tool

google-perftool provides a tool called pprof, which is a perl script. Through this tool, the output results of google-perftool can be analyzed more intuitively, and the output is in text, pictures, pdf and other formats.

Here we output the result through text: you just need to replace --gv with --texttml4

pprof ./main "/tmp/main.6712._main_-end.heap" --inuse_objects --lines --heapcheck --edgefraction=1e-10 --nodefraction=1e-10 --texttml4

OK, you can see that it is already obvious here, and you are prompted that there is a memory leak in the fifth line of the t.cpp file (of course you can also output other formats, raw, png, pdf, etc., whatever, as long as it can help you analyze the problem and solve the problem).

In fact, the memory leak problem encountered in the project is extremely complicated, and the example I gave is just a try. Everyone knows the common memory leak points in the project. New but no delete is obtained. However, it may take some effort to find the corresponding leak points based on the functions corresponding to the pprof tool.

In fact, most of your applications are started as services and are in a job/working state for a long time. You need to detect memory leaks regularly, so at this time you need to display the call interface to output leaks,

sample code 2

bool memory_check(void* arg){HeapLeakChecker::NoGlobalLeaks();return TRUE;}

Add the above code to your timing detection logic, or points that need to be observed, then it will output the content in Example 1 to help you analyze memory leaks dynamically.

related video recommendation

Analysis of the problem of memory surge and not falling after using tcmalloc

I remember a few years ago I started promoting people using tcmalloc, and some colleagues also encountered a lot of trouble in the process of doing pressure test . For example, when a large amount of data comes over, a lot of large chunks of memory comes out, and suddenly I find that sometimes the memory grows to a few G, and I start to think it is a memory leak problem.

First, he used the tcmalloc environment variable to check for memory leaks and found no leak reports. He also did a lot of tests with valgrind, but valgrind showed that there was no memory leak. In fact, don’t panic when encountering this kind of problem. It is basically a problem in the use of tcmalloc. You must know that by default, tcmalloc will return the memory that has not been used for a long time to the system. The flag tcmalloc_release_rate controls the return frequency. You can force this release to happen at runtime through this statement:

MallocExtension::instance()-ReleaseFreeMemory();

Of course, you can set this tcmalloc_release_rate through SetMemoryReleaseRate(). If set to 0, it means that it will never be returned. The larger the number, the greater the frequency of the return. A reasonable value is to set a number between 0 and 10. This rate can also be set by setting the environment variable TCMALLOC_RELEASE_RATE.

Actually, I guess many people read the official website

MallocExtension::instance()-SetMemoryReleaseRate(7.0);

was very confused. I once did a test with doubts and found that SetMemoryReleaseRate is set to 9, and the memory collected by 10 is still very slow, so I simply set SetMemoryReleaseRate to 9 at the beginning of the process startup, and then ReleaseFreeMemory when the new object is destructed. ReleaseFreeMemory once. (The life cycle of the object that comes out of new may be uncertain. It may exist for 1 day, 4 hours, 30 minutes, and it is not frequently released and destroyed). Therefore, in this case, the memory will be recycled in time, so you can choose the timing of ReleaseFreeMemory based on your project logic. It is best not to apply and release frequently, which is also uncomfortable for tcmalloc.

So you should not only pay attention to tcmalloc application memory blocks, but also pay attention to the timely recycling of memory blocks at the right time, otherwise it will cause excessive memory usage.