R
Ramasubbu Ramasubramanian XR (AS/EAB)
What is memory leakage, could any one explain with sample code
M
Mark Odell
Ramasubbu said:
When your program slowly consumes system memory.
int main(void)
{
char *pMembloc;
// Never free().
for (;
{
pMemblock = malloc(1024);
}
return 0;
}
N
not
void *X;
X = malloc(32768); // ok so far
X = malloc(16384); // you just orphaned the first block
free(X); // first block is now leaked.
When memory is allocated and not freed... they call it a "memory leak". Do
it often enough and eventually you end up with no free memory.
?
=?ISO-8859-1?Q?Jos=E9_de_Paula?=
Mark said:When your program slowly consumes system memory.
int main(void)
{
char *pMembloc;
// Never free().
for (;
{
pMemblock = malloc(1024);
}
return 0;
}
Slightly off-topic, when a program terminates, all the memory it had
allocated is returned to the system, right? (Yeah, I know, system
specific...) Or are there many systems that don't do that?
G
Gregory Toomey
Ramasubbu said:
Ask Bill Gates. I hadn't heard of the term until about 8 years ago.
http://msdn.microsoft.com/library/d...core98/html/_core_detecting_a_memory_leak.asp
At the application level, failing to free RAM allocated by malloc, or not going garbage collection, is one thing.
Bill Gates brought this to a new level by including memory allocation errors in the OS itself and in programming tools.
gtoomey
C
Chris Croughton
It's implementation defined. In practice, most hosted implementations
will do that because there are thousands (or more) of programs which
just exit and assume that the OS will clean up after them. However, at
least one MSDOS compiler at one time used two mechanisms for memory
allocation, small areas were allocated on the fixed space 'heap' and
large ones used a direct OS call, the latter weren't always cleanly
released. This was, however, pre-ANSI C (but I can't see anything in
the C99 standard which states that memory is or is not automatically
freed on program termination).
Chris C
T
Tor Rustad
Ben Pfaff said:
True, this is a QoI issue.
A conservative assumption is that we can replace "normal"
by "highly normal"? I guess Ben P. too remember, that Dan
Pop once gave an example of such an OS. There was also
another c.l.c. regular that didn't trust Windows NT, to do such
a cleanup properly in all cases.
N
Nils Weller
Some people keep saying that not free()'ing everything before program
termination is potentially dangerous, but I have never seen anyone
provide a *concrete* example of an implementation that actually requires
this to avoid memory leaks.
It appears that there are no such implementations, and even if you could
come up with one or two exotic, historical and barely used examples,
then they were highly unlikely to be a viable target for software
development in C today. And even if they do exist and are a viable
target to some, then the fact that the implementation cannot even clean
up all memory implies that it is a highly specialized and limited
platform where free() vs. no free() is just one among many other
problems that need to be addressed (or in other words: if you're writing
for such a system, then free() is the least of your worries, and
religiously calling free() all the time will not magically make your
code work well on it.)
The fact is that neither the C standard, nor the known C implementations
(unless someone can finally provide a counter example), provide any
basis for having to call free() before program termination.
I can't recall seeing Dan Pop mention an example implementation, but I
do recall him giving another good reason as to why the free() argument
is bogus: If the system cannot clean up the heap, what will happen to
all other memory of your program - the memory whose deallocation is even
more (and I say ``more'' because most common free() implementations do
not actually return anything to the operating system; In most cases they
just save it for subsequent malloc() requests, and the hardware page
size makes this technically impossible for small memory chunks anyway)
outside of your control, typically stack, code and data segments?
T
Tor Rustad
Nils Weller said:
As I said, Dan Pop gave _one_ such an example, I would put it
in the exotic & historical category, can't even remember what it
was called anymore.
The NT case, was never proven/demonstrated...
I more or less agree with this. However, if writing a non-stop server,
I care a lot about *not* leaking any memory. OTOH, short-lived
programs running on a stable kernel with VM support, I don't see the
problem with "memory leaking" at all.
Good point.
N
Nils Weller
Nils Weller said:
As I said, Dan Pop gave _one_ such an example, I would put it
in the exotic & historical category, can't even remember what it
was called anymore.
I recall that Dan Pop mentioned an example of a system where the
operating system is not capable of freeing the memory, but on that
implementation (Amiga, IIRC), the C runtime takes care of the issue, so
it is NOT an example of an implementation where you have to call free()
in order to prevent memory leakage. Or are you thinking of another
example? If so, please provide concrete references.
Nobody argued that memory leaks inside of your application are okay; We
are discussing whether or not not free()'ing all dynamically allocated
memory before program termination actually causes a leak that
subsequently affects the system and other applications running on it.
T
Tor Rustad
Nils Weller said:Nils Weller said:[...]
As I said, Dan Pop gave _one_ such an example, I would put it
in the exotic & historical category, can't even remember what it
was called anymore.
I recall that Dan Pop mentioned an example of a system where the
operating system is not capable of freeing the memory, but on that
implementation (Amiga, IIRC), the C runtime takes care of the issue,
so it is NOT an example of an implementation where you have to
call free() in order to prevent memory leakage.
Ahh.. yes Amiga DOS was the one! You are right, there was cleanup
code in the runtime library...
Dan's chief point, was that if a system isn't able to reclaim unfree'ed
memory on program termination, then the same would be likely for
the free'ed memory.
E
Emmanuel Delahaye
Ramasubbu Ramasubramanian XR (AS/EAB) wrote on 23/03/05 :
When you allocate some memory block and never free it. On 24h per day
running machines, such a behaviour is lethal.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.
When you allocate some memory block and never free it. On 24h per day
running machines, such a behaviour is lethal.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.
E
Emmanuel Delahaye
José de Paula wrote on 23/03/05 :
Daemons don't terminate... They eat memory...
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"There are 10 types of people in the world today;
those that understand binary, and those that dont."
Daemons don't terminate... They eat memory...
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"There are 10 types of people in the world today;
those that understand binary, and those that dont."
C
CBFalconer
Tor said:
OTOH there are cases when you want to let the OS do the cleanup.
Most malloc systems out there have an O(n) free algorithm, where n
is the number of blocks, allocated or freed, in existence. The n
arises from the efforts to join adjacent freed blocks. This means
that the programs final effort to free the large n blocks it has is
O(n*n), and can be very annoying.
Some of the test cases for hashlib can easily trigger this
behavior. Those cases have the option of just not doing the final
free sequence. I found the bad behaviour on every system I tested.
I ran into this very annoying behaviour during testing of hashlib,
and the result was the writing of nmalloc, to eliminate the O(n)
free [now O(1)]. Both are available at:
<http://cbfalconer.home.att.net/download/>
K
Keith Thompson
Ben Pfaff said:
The standard doesn't guarantee that un-free()d memory is reclaimed
when the program terminates.
The standard also doesn't guarantee that free()d memory is reclaimed
when the program terminates.
Calling free() causes a memory block to become available for further
allocation within the program; it doesn't necessarily return it to the
operating system (and it typically doesn't). The standard doesn't say
what happens when the program terminates.
(Having said that, an OS that doesn't reclaim even free()d memory on
program termination would be painful.)
J
Jack Klein
That depends on the system, something over which the C language
standard has no control. It is a QOI issue with the platform.
Even assuming that a compiler's C run time library walked its active
allocation list and free'd everything after main() returned or exit()
was called, sometimes programs crash, preventing any clean up in the
run time library from executing.
As for those who ask for concrete examples, there were early versions
of MS-DOS, 2.x for sure and I think 3.x, the could lose it if a
program terminated without deallocating memory it allocated while
running. You would end up with a prompt on the screen something like
"Can't load command.com, system halted".
L
Lawrence Kirby
That's not quite right. A memory leak is where a memory block hasn't been
freed, but the program loses all means to reference it. A related but
subtly different situation is where a program doesn't free a memory block
it no longer needs, but still maintains the ability to reference it. E.g.
garbage collection systems can help with the former but not the latter.
It is quite possible for a correct program to allocate memory and never
free it, indeed it is common. For example the program can maintain
data that is relevant right up until the program terminates. The downside
here is debugging, some debugging environments can report unfreed memory
allocations on program termination as potential memory leaks. The utility
of this is greatly reduced if the program doesn't clear up allocated
memory.
There have been discussions as to whether C requires memory to be "freed"
on program termination. It doesn't, but that's the wrong question -
dynamic memory allocation space (sometimes referred to as a "heap") only
exists in the context of the program's execution environment, i.e. when
the program terminates the "heap" no longer exists. The more useful
question is whether when the program terminates memory allocated by the
program is reclaimed by whatever OS/environment caused the program to be
run in the first place. This is outside the scope of the
execution/behaviour of the C program so the standard says nothing about it.
It has been argued that since C doesn't require unfreed memory to be
reclaimed on program termination, that is a reason to make sure
that all allocated memory is freed. However C doesn't require that any
resources used by the C program be reclaimed (except that files be closed
on normal termination); static, automatic variables, program code and even
freed memory need not be reclaimed either. So this is not itself a reason
to free memory. It is possible that real-world implementations don't
reclaim unfreed memory but that's rare to non-existant these days.
The problem tends to be when a program does either of the above
repeatedly, i.e. keeps more and more memory allocated that it no longer
uses.
Lawrence
T
Tor Rustad
Yes. To have a stable OS, the kernel need to run in a protected
memory space and to control memory cleanups after programs
terminating in user space.
Even if the runtime library register a __freeall() function, which is
called in case of interrupts/exceptions, the runtime library can't
protect against wild pointers corrupting the heap arena (unless
using protected memory space).
Did DOS run x86 in protected mode before Windows came along?
I can't recall that I had problems reading/writing to any memory
address under DOS. C programming & DOS was... "fun".
However, even in case of a program crash, it isn't obvious that
explicit free() calls, would change anything w.r.t. memory leaks.
T
Tor Rustad
Agreed. It should however be pointed out that we here talk about
programs that run in "user space". Let say our program is part of
a kernel or is a device driver, then such code must take great
care in manually free'ing allocated memory.
For example on Linux, kmalloc()/kfree() and vmalloc()/vmfree() take
the role of malloc()/free().