阿神2017-04-17 13:03:37
The increasing memory is not necessarily a memory leak, it may also be a cache made by yourself
I think the more elegant answer to this question is:
1) First determine whether it is a memory leak, and whether the memory will be occupied for a long time. Release (some programs have created their own memory pool, which will trigger the release themselves) is a leak, otherwise it may be that there is a cache inside the program, or it may be that the program itself has pooled memory management
2) Use static analysis tools first Check possible memory leaks
3) Memory leaks during runtime cannot be detected by tools. You need to analyze them yourself. One thing about C++ compared to BT is that memory leaks are implicit, not explicit. If the entire program is completely It is a static library. You can test the interface to confirm which module is causing the leak. If there is a dynamic library included in it, it is also recommended to test the interface first to confirm which modules will cause the memory leak, and then confirm the interface. Check whether the calls are normal and see if there are any invisible leaks. There are also some tools such as purify that can print some stack information, but for particularly complex environments, this help is still limited. Moreover, Windows and Linux have different implementations of certain features of C++, which may also cause leaks. I once saw a library running very stably under Linux, but it would cause inexplicable leaks under Windows (the same source code, support Cross-platform)
巴扎黑2017-04-17 13:03:37
We use Valgrind.
In addition, in terms of answering this interview question, I think you can answer it this way: calling brk(0) returns the top address of the heap..
