This article is limited to recording your own memory leak tracking notes. may not be very well suited to the situation with everyone. And the method is not very smart. Only record, can provide a better idea.
first, to ask the debug program what problems the most headaches, memory leaks must be ranked in the first few. Memory leaks are generally due to the fact that they do not use the correct pair of pairs in the process of requesting and releasing memory. There was a case where memory was requested but not released or freed. Memory leak problems may not have a significant impact in a short period of time. However, if you run the program for a long time, the memory is gradually eroded. The situation that causes the server (host) to work abnormally, seriously causes other program to be unable to work normally, even the situation of the outage. Ii. encountering and discovering memory leaks
The problem of memory leaks must not be seen at a glance. This is typically a long-term observation, or a situation that repeats itself, and looks at the memory usage, and discovers that the memory available values are progressively reduced. And after the execution of the condition is stopped, memory usage is not restored. At this point, there is a large likelihood of a memory leak problem.
Iii. Finding the necessary conditions for memory leaks
A memory leak was found. The most important thing is to find the necessary conditions for a memory leak. It is best to find the most sharply leak condition. This process may be longer, if the situation is simpler, it's okay to say. A few conditions try to basically can touch a nearly! However, if you encounter a more complex situation, then the multi-clock condition combination test is required. To arrive at the most fundamental of the conditions that lead to leakage, success is not far away!
Iv. Finding the code for memory leaks
with the condition that the problem must be present, the next step is to follow the code (nonsense ...). ）。 According to the condition of the processing process a little bit of code, to see the allocation and release of memory. See if there is a case for less release. But this method is the stupidest way. (1) Introduction of a tool Valgrind, although in my debug phase did not give much help, but also helped a bit busy. But it's not a good way to boast. It's a great tool for tracking memory problems.
refer to the IBM great God article for the specific use method http://www.ibm.com/developerworks/cn/linux/l-cn-valgrind/
Tell me about its advantages:
There is no need to intentionally insert new tracking code into your code. Add the-G option only when compiling executable programs. You can use the Valgrind tool to debug it in memory. Method is simple.
But one thing, in the program I'm using, is a big loop. and is a daemon process. The use of Valgrind is a bit inconvenient! Must present condition executes once, very slow ... So according to the actual use of your program, screening selection. If there is no other way of thinking, you can use the tool to run a bit, probably solved it! (2) Stupid method in calling Malloc/new, Free/delete and other applications, free memory functions, print the application process and some basic information (the size of the application space, address, you can also use a global variable to write down the number of applications, releases). In order to observe which block had been applied, but did not find the corresponding release place.
In Summary, there is no easy way to resolve memory leaks. The prevention method is to standardize their own code writing, to do a good job of the application and release. Remember to release the memory you requested before you return and exit when handling exception conditions. Develop a good habit of coding. Or when architecting software code, you can encapsulate the memory request, release function, and add your own debugging information. A lot of necessary debugging information to solve the problem is a great help. do not worry too much about memory leaks. Don't worry about solving problems quickly. If it's not the kind of thing that can be revealed at a glance, it's basically not going to take a short time. So keep your passion for debugging, don't be discouraged. Most of the solutions to the most intractable problems are missing a few lines of code. When you find a solution, don't feel like you're a rookie. It took a long time to think of such a simple problem. What is important is the process of solving the problem. If you don't solve a problem, you make progress once.
Linux Memory Leak Summary
