sonal

• Jun 8th, 2005

 

a memory leak occurs when mem is allocated but never freed . leakes can b caused by using malloc() without using any free(). 
but leaks can also be caused if a pointer to dynamically allocated memory is delleted overwritten , it can be caused when allocated mem is overwritten accidentally

lohith

• Dec 16th, 2005

 

when we allocate memory dynamically, but it will loose the way to reach that memory then we are saying memory leak

Guru

• Mar 23rd, 2006

 

Memory leaks can be occured if no allocated memory is freed. for example,malloc() and free().It is always a good practice to release the memory because it can be dangerous. it could afftect the whole program and lead to very difficult situtation. Make sure that you are releasing the allocated memory at time. so next time you write program, think twice before allocating memory. I always writedown a notes before i start program. so i know whats going on.

Ravikumar

• Jul 14th, 2006

 

        Memory leak example occurs when a developer allocates memory, assigns it to a pointer, and then assigns a different value to the pointer without freeing the first block of memory. In this example, overwriting the address in the pointer erases the reference to the original block of memory, making it impossible to release.

Jerry

• Jul 26th, 2006

 

The former example explains dangling pointers which are a form of leaked memory. In book terms though, the former explanations are more true. Any memory malloc'd or new'd in C++ and not free'd or delete'd will leak memory.There is a popular assertion that UNIX systems can do garbage collection by default. We believe this because process boundaries prevent us from acquiring dangling pointers or un-free'd memory from another process. This leads to a false sense that UNIX is mothering us more than we believe. UNIX/C and C++ DO NOT do default garbage collection. We must be better stewards of our memory allocated to us.Also the former point is true because UNIX is so impervious to leaked memory that only at the last moment where the program can not get more memory from malloc do we see a UNIX system "give up the ghost".There is also a misunderstanding that another more incidious enemy is actually a memory leak. And THESE types are the ones we tend to run-down and falsely label as memory leaks. These events are truly variable space that we've overrun.Most experienced C/C++ programmers call it "overrun memory". The explanations are this; we don't allocate enough static or dynamic memory to handle our true memory requirements. Suppose we want to save 'Jerry' in the user_name portion of a getty type program. In 'C' we all know this has to go into a char user_name[6]. But more often than not we dumbingly put char user_name[5] as the location. If the next variable in line is an interger or some primitive type 'C' just agrees that you want to save by; sprintf(user_name, "%s", 'Jerry'); guess what? Your NULL byte just went into the first byte or last byte (BIG ENDIAN or LITTLE ENDIAN) of the next variable. Boom, when you go to eval that location you get a ill-behaved program.Don't get me wrong we all do it. It's very difficult to prevent this coding faux pas.