Linux: no memory leakage

Linux: no memory leakage-Linux general technology-Linux programming and kernel information. For more information, see the following. This article describes how to detect memory leaks and the tools that can be used now. This article provides sufficient information to address the memory leakage issue, so that we can make choices among different tools.

　　
　　 Memory leakage
　　
　　
Here we are talking about memory leaks and errors in programming. However, not all programs have this problem. First, some memory problems such as leaks are not easy in some programming languages. These programming languages generally think that memory management is too important, so they cannot be handled by programmers. It is better to be handled by program language designers. Such languages include Perl and Java.
　　
However, in some languages (the most typical ones are C and C ++), the program language designers also think that memory management is too important, but it must be handled by developers themselves. Memory leakage means that the programmer dynamically allocates the memory, but forgets to release it after use. In addition to memory leakage, some memory problems such as buffer overflow and suspension pointer also occur in the development of the developer's memory management.
　　
　　
　　 Why?
　　
　　
To enable the program to process the memory size that cannot be predicted during compilation, the program must apply for memory in real time from the operating system. This is called dynamic memory. At this time, there will be an error that the program did not return it to the operating system after applying for a memory block and using it. Worse, the address of the obtained memory block is lost, and the system cannot identify or locate the memory block. There are other problems, such as trying to access the released pointer (hanging pointer) and accessing the used memory (memory overflow.
　　
　　
　　 The consequences cannot be ignored
　　
　　
For programs that are not resident in memory, the execution process is very short, so even a vulnerability may not cause serious consequences. However, for some resident memory programs (such as Apache on the Web server), if such problems occur, the consequences will be very serious. Because problematic programs constantly apply for memory from the system and do not release the memory, the system may eventually run out of memory and cause the system to crash. In addition to occupying more memory, programs with Memory leakage can also cause a sharp decline in program performance. If this happens to the server, even if the system does not crash, it will seriously affect the use.
　　
Hanging pointer may lead to some potential risks, and these risks are not prone to outbreaks. It is not obvious, so it is hard to be found. Among the three problems, buffer overflow may be the most dangerous. In fact, it may cause many security issues (a secure program contains many elements, but the most important thing is to be careful with memory usage ). As mentioned above, sometimes the same memory block is returned to the system multiple times, which is also a program design error. A programmer wants to know the memory usage during the program running, so as to discover and correct the problem.
　　
　　
　　 How to handle
　　
　　
Now we have some technologies to monitor memory problems in real time. Memory leakage can be detected and solved by regularly terminating and restarting problematic programs. In the new Linux kernel version, there is an algorithm named Out Of Memory killer, which can execute programs such as Killed if necessary. The pendulum pointer can be fixed by regularly setting zero for all memory that has been returned to the system. There are many solutions to the memory overflow problem.
　　
As a matter of fact, it is much more difficult to solve these problems when the program is running, so we hope to discover and solve these problems when developing the program. The following describes some available free software.
　　
　　
Tool 1: Garbage Collector (GC)
　　
　　
In the GCC (download) Toolkit, there is a "Garbage Collector (GC)" that can easily detect and fix many memory problems. HP's Hans-J.Boehm is currently responsible for this project.
　　
　　 Technologies used
　　
GC uses a technology called Boehm-Demers-Weiser that can continuously track memory positioning. Its algorithm is implemented by using standard memory positioning functions. The program uses these functions for compilation and execution, and the algorithm will analyze the operations of the program. This algorithm is well-known and easy to understand and does not cause problems or interfere with programs.
　　
　　 Performance
　　
This tool has good performance, so it can effectively improve program efficiency. The code is very small and can be used directly in GCC.
　　
This tool has no interface and is difficult to use, so it still takes some time to grasp it. Some existing programs may not be able to use this editor for configuration. In addition, in order for all calls to be captured, all memory calls (such as malloc () and free () must be replaced by the corresponding functions provided by GC. We can also use macros to complete this task, but we still feel that it is not flexible enough.
　　
　　 Conclusion
　　
If you want to have a cross-platform (architecture, operating system) solution, that's it.
　　
　　
Tool 2: Memprof
　　
　　
Memprof (download) is an attractive and easy-to-use software created by Red Hat's Owen Talyor. This tool is the Boehm-Demers-Weiser Garbage Collector for GNOME front-end.
　　
　　 Technologies used
　　
For its core technology, Memprof is essentially different from the GC mentioned above. However, when this function is implemented, it captures all memory requests from the program and migrates them to the garbage collector in real time.
　　
　　 Performance
　　
The performance of this tool is very good, and its GUI is also well designed (1 ). This tool can be executed directly without any modifications to the source code. During program execution, this tool displays the memory usage in a graphical manner to help you understand the memory application status during the program running process.

Currently, this tool can only run on Linux systems with x86 and PPC architectures. If you want to use it on other platforms, consider using other tools. This tool is not a GTK application, so a complete GNOME environment is required. In this way, it cannot be used flexibly in all places. In addition, the development of this tool is also relatively slow (version 0.4.1 ).
　　
　　 Conclusion
　　
If you like the GUI tool and don't mind using it only for Linux and GNOME, it should be very good.
　　
　　
Tool 3: Valgrind
　　
　　
Valgrind (http://developer.kde.org /~ Sewardj/) is a program dedicated to solving all memory problems, and memory leakage is only one of the problems. The developer of this tool is Julian Seward (known for Bzip2 and Cacheprof ). The tool claims that it is "dedicated to solving the problem of open-source memory in x86 Linux". In fact, it does implement its own declaration. In addition, it can also describe the usage of CPU cache, but this function is not commonly used.
　　
　　 Technologies used
　　
The technology used in this program is very complex, but its documentation is very rich and complete (http://developer.kde.org /~ Sewardj/docs/techdocs.html ). Each byte of memory allocated by the program is tracked by a nine-bit stateful word to identify its intent. This method greatly increases the burden on the system.
　　
　　 Performance
　　
This tool is the worst performing of the three described here, for obvious reasons. The tool provides the most detailed information among the three tools, so the speed is also the slowest. In addition to some common problems, this tool can also discover other memory problems, and even some POSIX thread problems. Buffered information does not seem necessary for most programs, but it is a good way to view program performance. For Valgrind, it is worth mentioning that its development speed is very fast and Its Development Community is also very active. In fact, on the Valgrind homepage, the author even says, "If you have any problems when using Valgrind, please don't mind. Send me an email ".
　　
However, this tool is dedicated to x86. Its interface is a command line method, but its availability is very good. This tool can be run directly in binary, so it does not need to be re-compiled during use. However, to be familiar with it, you still need to make some effort. In addition, although the tool was used in large thread programs such as Mozilla and OpenOffice, the tool's support for threads is not complete. I think if the tool has a GUI, it will win more people's favor.
　　
　　 Conclusion
　　
If you use x86 and have a good understanding of your code and do not mind using the command line method, this program will be your favorite.
　　
If you don't like the three tools I 've introduced here, it doesn't matter. You can find a lot of tools for detecting memory errors on the following sites: http://www.sslug.dk/emailarkiv/bog/20042608/msg00030.html. There are also some commercial tools such as Purify and Geodesic. We will not detail it here.