What is memory leakage

[Ramasubbu Ramasubramanian XR (AS/EAB)]

What is memory leakage, could any one explain with sample code

[Mark Odell]

Ramasubbu Ramasubramanian XR (AS/EAB) wrote:

What is memory leakage, could any one explain with sample code

When your program slowly consumes system memory.

int main(void)
{
char *pMembloc;

// Never free().
for (;;)
{
pMemblock = malloc(1024);
}

return 0;
}

[José de Paula]

Mark Odell wrote:

Ramasubbu Ramasubramanian XR (AS/EAB) wrote:

What is memory leakage, could any one explain with sample code

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?

[Gregory Toomey]

Ramasubbu Ramasubramanian XR (AS/EAB) wrote:

What is memory leakage, could any one explain with sample code

Ask Bill Gates. I hadn't heard of the term until about 8 years ago.
http://msdn.microsoft.com/library/de...emory_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

[Ben Pfaff]

Josi de Paula <jo***********@ig.com.br> writes:

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?

This is "normally" the case, but it is not guaranteed by the
standard.
--
"The fact that there is a holy war doesn't mean that one of the sides
doesn't suck - usually both do..."
--Alexander Viro

[Tor Rustad]

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message

Josi de Paula <jo***********@ig.com.br> writes:

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?

This is "normally" the case, but it is not guaranteed by the
standard.

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.

--
Tor <torust AT online DOT no>

[Chris Croughton]

On Wed, 23 Mar 2005 11:56:02 -0300, José de Paula
<jo***********@ig.com.br> wrote:

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?

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

[Nils Weller]

In article <Zl******************@news2.e.nsc.no>, Tor Rustad wrote:

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message

Josi de Paula <jo***********@ig.com.br> writes:

> 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?
This is "normally" the case, but it is not guaranteed by the
standard.

True, this is a QoI issue.

A conservative assumption is that we can replace "normal"
by "highly normal"?

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 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.

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?

--
My real email address is ``nils<at>gnulinux<dot>nl''

[Tor Rustad]

"Nils Weller" <[e-mail]> wrote in message

In article <Zl******************@news2.e.nsc.no>, Tor Rustad wrote:

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message

This is "normally" the case, but it is not guaranteed by the
standard.
True, this is a QoI issue.

A conservative assumption is that we can replace "normal"
by "highly normal"?

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.

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...

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 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.

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?

Good point.

--
Tor <torust AT online DOT no>

[Nils Weller]

In article <ZI******************@news2.e.nsc.no>, Tor Rustad wrote:

"Nils Weller" <[e-mail]> wrote in message

In article <Zl******************@news2.e.nsc.no>, Tor Rustad wrote:

> "Ben Pfaff" <bl*@cs.stanford.edu> wrote in message

[...]
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.

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.

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 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.

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.

--
My real email address is ``nils<at>gnulinux<dot>nl''

[Tor Rustad]

"Nils Weller" <[e-mail]> wrote in message
news:3a*************@individual.net...

In article <ZI******************@news2.e.nsc.no>, Tor Rustad wrote:

"Nils Weller" <[e-mail]> wrote in message

In article <Zl******************@news2.e.nsc.no>, Tor Rustad wrote:

[...]
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.

--
Tor <torust AT online DOT no>

[Emmanuel Delahaye]

Ramasubbu Ramasubramanian XR (AS/EAB) wrote on 23/03/05 :

What is memory leakage, could any one explain with sample code

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.

[Emmanuel Delahaye]

José de Paula wrote on 23/03/05 :

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?

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."

[CBFalconer]

Tor Rustad wrote:

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message

Josi de Paula <jo***********@ig.com.br> writes:

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?

This is "normally" the case, but it is not guaranteed by the
standard.

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.

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/>

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Keith Thompson]

Ben Pfaff <bl*@cs.stanford.edu> writes:

Josi de Paula <jo***********@ig.com.br> writes:

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?

This is "normally" the case, but it is not guaranteed by the
standard.

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.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Jack Klein]

On Wed, 23 Mar 2005 11:56:02 -0300, José de Paula
<jo***********@ig.com.br> wrote in comp.lang.c:

Mark Odell wrote:

Ramasubbu Ramasubramanian XR (AS/EAB) wrote:

What is memory leakage, could any one explain with sample code

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?

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".

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Lawrence Kirby]

On Wed, 23 Mar 2005 21:58:44 +0100, Emmanuel Delahaye wrote:

Ramasubbu Ramasubramanian XR (AS/EAB) wrote on 23/03/05 :

What is memory leakage, could any one explain with sample code
When you allocate some memory block and never free it.

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.
On 24h per day
running machines, such a behaviour is lethal.

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

[Tor Rustad]

"Jack Klein" <ja*******@spamcop.net> wrote in message

<snip>

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.
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).

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".

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.

--
Tor <torust AT online DOT no>

[Tor Rustad]

"Lawrence Kirby" <lk****@netactive.co.uk> wrote in message

<snip>

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.

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().

--
Tor <torust AT online DOT no>