Talking about Memory Leakage (1)
For a C / C programmer, memory leaks is a common and headache problem. There have been many technologies to be studied to deal with this problem, such as Smart Pointer, Garbage Collection, etc. Smart Pointer technology is relatively mature, and the STL already contains Class of Smart Pointer, but its use does not seem broad, and it does not solve all the problems; Garbage Collection technology is more mature in Java, but in C / C field The development is not smooth, although some people think about the support of GC in C . The real world is like this, as a C / C programmer, memory leak is your feelings in your heart. However, in now there are many tools to help us verify the existence of memory leaks, find out the code that has problems.
Definition of memory leakage
Generally, the memory leakage is the leakage of the reactor memory. The stack memory is that the program is allocated from the heap, the size is arbitrary (the size of the memory block can be determined in the program running period), and the released memory must be displayed after use. Applications generally allocate functions such as Malloc, Realloc, New, from the heap, after use, the program must be responsible for the corresponding call free or delete release the memory block, otherwise, this memory cannot be used again, we will Said this memory leak. The following small program demonstrates the situation of leakage in the stack of memory:
Void myfunction (int nsize)
{
Char * p = new char [nsize];
IF (! GetStringFrom (p, nsize)) {
MessageBox ("error");
Return;
}
... // using the string pointed by p;
Delete P;
}
Example
When the function getStringFrom () returns zero, the memory pointed by the pointer P is not released. This is a common situation in which memory leaks occur. The program allocates memory at the entrance, releases memory at the exit, but the C function can exit anywhere, so once the memory that should be released at an exit, the memory leak will occur.
Generalized saying that memory leaks not only contains leaks of stacks, but also contains resource leaks, such as core states, GDI Object, Socket, Interface, etc., fundamentally, these objects allocated by the operating system are also The memory is consumed, and if these objects, the leakage will ultimately lead to the leakage of memory. Moreover, some object consumes core state memory, which will cause the entire operating system unstable when it is severely leaked. Therefore, the leakage of system resources is more serious than the leakage of the stack memory.
Leakage of GDI Object is a common resource leak:
Void CMYVIEW :: OnPaint (CDC * PDC)
{
CBITMAP BMP;
CBITMAP * POLDBMP;
Bmp.LoadBitmap; IDB_MYBMP;
PoldBMP = PDC-> SELECTOBJECT (& BMP);
...
IF (Something ()) {
Return;
}
PDC-> SELECTOBJECT (POLDBMP);
Return;
}
Example
When the function Something () returns non-zero, the program does not select the PoldBMP back to the PDC before exiting, which will lead to the HbitMap object to PoldBMP. If this program is run for a long time, it may cause the entire system. This problem is easier to expose under Win9X because Win9x's GDI stack is much smaller than Win2K or NT. Memory leakage:
Classify in the way, memory leaks can be divided into 4 categories:
1. Avantime memory leak. The code that occurs in memory leaks will be executed multiple times, and a memory leak will be caused each time it is executed. For example, if the Something () function has returned True, the HbitMap object points to PoldBMP always leaks.
2. Appetitive memory leak. The code that occurs in memory leaks only occurs under certain specific environments or operations. For example, if the Something () function returns TRUE in a particular environment, the HBitMap object pointing to PoldBMP does not always leak. Avantages and occasionalities are relative. For a specific environment, the suspended may become a normal. So the test environment and test methods are critical to detect memory leaks.
3. Disposable memory leakage. The code that has a memory leak will only be executed once, or due to the defects on the algorithm, there will always be only a piece of only and one memory leak. For example, allocate memory in the constructor of the class, but does not release the memory in the destructuring function, but because this class is a Singleton, the memory leak will only occur once. another example:
Char * g_lpszfilename = null;
Void setFileName (const char * lpcszfilename)
{
IF (g_lpszfilename) {
Free (g_lpszfilename);
}
g_lpszfilename = strdup (lpcszfilename);
}
Example three
If the program does not release the string pointing to the g_lpsfilename at the end, even if setFileName () multiple times, there will always be a memory, and there is only one memory that leaks.
4. Implicit memory leaks. The program is constantly allocated during the running process, but the memory is released until the end. Strictly speaking, there is no memory leak, because the final program releases all application memory. But for a server program, it is necessary to run a few days, several weeks or even months, and the memory may not be released in time may result in all memory of the final depletion system. Therefore, we call such memory leaks for implicit memory leaks. As an example:
Class Connection
{
PUBLIC:
Connection (socket s);
~ Connection ();
...
Private:
Socket_socket;
...
}
Class ConnectionManager
{
PUBLIC:
ConnectionManager () {
}
~ ConnectionManager () {
List
For (it = _Connlist.begin (); it! = _Connlist.end (); IT) {
Delete (* it);
}
_Connlist.clear ();
}
Void OnClientConnected (Socket S) {
Connection * P = New connection (s);
_Connlist.push_back (p);
}
Void OnClientDisconnected (Connection * PConn) {_ connlist.remove (pconn);
DELETE PCONN;
}
Private:
List
}
Example four
Suppose After the client is open from the Server end, Server does not call the onClientDisconnected () function, then the Connection object representing the connection will not be deleted in time (when the Server program exits, all Connection objects will be analyzed in ConnectionManager. The constructor is deleted). When there is a continuous connection, it happens when it is disconnected.
From the perspective of the user using the program, the memory leak itself does not happen, as a general user, it does not feel the existence of memory leaks. Really harmful is the accumulation of memory leaks, which will eventually exhaust all the memory of the system. From this perspective, there is no harm of disposable memory leaks because it does not accumulate, and the harmful memory leakage is very large, because it is more difficult to detect more than a haired and occasive memory. .
(All rights reserved, please indicate when reprint)
