reason for memory leakage in C C++

what are the reasons for memory leakage in C C++ (except the usual all开发者_开发知识库ocating memory and forget to deallocate it)

---

If an exception is raised between allocation and deallocation, memory leak will occur.

void f1() {
    int* ptr = new int;

    // do something which may throw an exception

    // we never get here if an exception is thrown
    delete ptr;
}

Each time f1 terminates with an exception, 4 bytes are leaked (assuming int is 4 byte).

---

A memory leak is caused when you allocated memory, haven't yet deallocated it, and you will never be able to deallocate it because you can't access it anymore.

For example, the following code causes a memory leak of size sizeof(int):

int * a = malloc(sizeof(int)); //allocate memory
a = 0; //this will cause a memory leak

This creates a memory leak, because now we will never be able to deallocate the memory allocated for a.

---

You can also leak memory when you don't deallocate some other resource like not calling fclose on a FILE* or some other library handle because they can allocate buffers of memory that aren't directly accessible to your program.

---

Let's say you have created a class that inherits some other class that doesn't have a virtual destructor. If the type of the pointer to this class isn't the most derived class (this usually happens if you use an abstract factory) then only the destructor from the pointer's type will be called and anything you had been hoping do free in the most derived class destructor will leak.

This is a very common error and one that some times is hard to see.

Anyway, if you want to avoid memory leaks with C++ follow this rules:

• Prefer passing references rather than pointers
• Use smart pointer whenever possible (see: shared_ptr)

---

A new without a delete, a new[] without a delete[], a malloc without a free.

Seriously, what else do you want to hear?

---

There is no other reason for memory leakage besides the one you mention

---

I'm surprised nobody mentioned memory corruption yet.

I remember a case when we had a crude fixed-size blocks memory allocator implemented as a linked list.

Some guy had messed up size computations, leading to copy data just a couple of bytes beyond the max block size (pointers were only 2 bytes long at the time :)). It would then overwrite the "next" link located at the begining of the next free block with garbage that happened to be filled with zeroes.

This had the consequence of severing the free blocks chain. Since at that point the other pieces of software maintained their own pointers to whatever blocks they were using, the progam seemed to run just fine.

But of course the list went short of a few blocks once in a while, and this leakage eventually exhausted the free blocks, starving the application to death.

---

The following example, written in pseudocode, is intended to show how a memory leak can come about, and its effects, without needing any programming knowledge. The program in this case is part of some very simple software designed to control an elevator. This part of the program is run whenever anyone inside the elevator presses the button for a floor.

When a button is pressed:

  Get some memory, which will be used to remember the floor number
  Put the floor number into the memory
  Are we already on the target floor?
    If so, we have nothing to do: finished
    Otherwise:
      Wait until the lift is idle
      Go to the required floor
      Release the memory we used to remember the floor number

The memory leak would occur if the floor number requested is the same floor that the lift is on; the condition for releasing the memory would be skipped. Each time this case occurs, more memory is leaked.