On the memory leak (1)
For a c / c + + programmers, the memory leak is a common cause for headache. There are already many techniques have been proposed to address this problem, such as Smart Pointer, Garbage Collection, etc.. Smart Pointer relatively mature technology, STL has already included support for Smart Pointer of the class, but it seems not widely used, but it can not solve all problems; Garbage Collection in Java, are already quite mature, but in c / c + + area The development is not smooth, although some early thinking in C + +, also joined the GC support. The real world is like this, as a c / c + + programmer, the memory leak is the pain in your heart forever. Luckily, there are many tools to help us verify the existence of a memory leak, identify the problem code.
The definition of a memory leak
We often say that generally refers to the memory leak heap memory leaks. Program heap memory is allocated from the heap, the size of any (memory block size can be run on the decision), released after use to display memory. Applications generally use malloc, realloc, new and other functions assigned to the block of memory from the heap after use, the program must be responsible for the corresponding call to free or delete the release of the block of memory, otherwise, this memory can not be used again, we that this memory is leaked. The following program demonstrates this small heap memory leak case:
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 One
When the function GetStringFrom () returns zero when the pointer p point to the memory will not be released. This is a common case of memory leak. Procedures at the entrance to allocate memory, the memory in the release of the exit, but the c function can quit at any place, so if there is an exit should be released without the release of memory, a memory leak occurs.
Broadly speaking, memory leaks, not only contains the heap memory leak, also includes the leakage of system resources (resource leak), such as the core state HANDLE, GDI Object, SOCKET, Interface, etc. Basically these objects are allocated by the operating system consumption of memory, and if these objects will eventually lead to leakage of memory leak. Moreover, consumption of certain objects is the core state memory, these objects will cause severe leakage throughout the operating system unstable. So contrast, system resources leak heap memory leaks than more serious.
GDI Object leak 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;
)
[Next]
Example Two
When the function Something () returns non-zero, the program does not quit before the election back to pOldBmp pDC, this will lead to pOldBmp point to the HBITMAP object leak. If the long run this procedure may cause the entire system Huaping. This problem is easily exposed under Win9x, because the GDI heap than Win9x or NT, Win2k much smaller.
Memory leak occurs by:
Way to place the classification of a memory leak can be divided into four categories:
1. Often made of a memory leak. Memory leak in the code will be repeatedly executed, when each is executed will lead to a memory leak. Such cases two, if Something () function always returns True, then the pOldBmp HBITMAP object always points to a leak.
2. Episodic memory leak. The code memory leak occurs only in certain environments or under the operation will occur. Such cases two, if Something () function only in specific circumstances only to return True, then the pOldBmp HBITMAP object does not always point to the leak. Regular and occasional hair is relative. For a particular environment, and perhaps occasional became often made of. So the test environment and test methods for detecting memory leaks is essential.
Three. A one-time memory leak. Memory leak in the code will be executed once, or because of algorithm flaws, there is always a just cause and a memory leak. For example, in the class constructor to allocate memory in the destructor does not release the memory, but because this class is a Singleton, so the memory leak only happens 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 at the end of the string does not release g_lpszFileName point, then, even if multiple calls SetFileName (), there will always be a memory, and only one memory leaks.
4. Implicit memory leak. Program kept running during the distribution of memory, but only until the end of the free memory. Strictly speaking, there is no memory leak here, because the final procedures for the release of all the memory. But for a server program, need to run a few days, weeks or even months, without timely release of the final run out of memory can also cause all the memory system. Therefore, we call this type of memory leak as the implicit memory leak. Give an example:
class Connection
(
public:
Connection (SOCKET s);
~ Connection ();
...
private:
SOCKET _socket;
...
);
class ConnectionManager
(
public:
ConnectionManager () (
)
~ ConnectionManager () (
list:: iterator it;
for (it = _connlist.begin (); it! = _connlist.end (); + + it) (
delete (* it);
[Next]
)
_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 _connlist;
);
Example Four
Assuming Client disconnected from the Server side, Server does not call OnClientDisconnected () function, then the connection on behalf of the Connection object that will not be timely removed (in the Server program exits when all the Connection object of analysis in ConnectionManager structure function is deleted). When there is continuous connection is established, disconnected implicit memory leak happened.
Use the program from the user point of view, the memory leak itself does not produce any harm, as a general user, simply do not feel the existence of a memory leak. Real damage is the accumulation of memory leaks, which will eventually consume all system memory to do. From this perspective, a one-time memory leak no hazard, because it does not accumulate, while the implicit danger of memory leak is very large, as compared to regular fat, and occasional memory leak it more difficult to be detected.
Recommended links:
ThinkPad First National USER Conference held in Beijing
Comparison Registry Tools
A MOVE into a digital video camera to camera
car gps
TD COMMERCIAL trial on April 1 the minimum consumption of 118 yuan a complete experience
Catalogs Newsgroup Clients
MP4 to WMP
IM: Decisive Force's crowded
Describes the Properties of the problem MIDP
Simple Trace And Ping Tools
Unicom's First Response To IPhone Parallel: Black-earned Money Through Tax Evasion
ASF TO MPG
Passion in June, feast Of Mach 5 Group buy
MKV To WMV
Infomation Accounting And Finance
