472,952 Members | 2,152 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,952 software developers and data experts.

What is memory leakage

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

Nov 14 '05 #1
18 2201
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;
}

Nov 14 '05 #2
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?
Nov 14 '05 #3
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
Nov 14 '05 #4
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
Nov 14 '05 #5
"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>

Nov 14 '05 #6
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
Nov 14 '05 #7
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''
Nov 14 '05 #8
"Nils Weller" <me@privacy.net> 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>
Nov 14 '05 #9
In article <ZI******************@news2.e.nsc.no>, Tor Rustad wrote:
"Nils Weller" <me@privacy.net> 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''
Nov 14 '05 #10
"Nils Weller" <me@privacy.net> wrote in message
news:3a*************@individual.net...
In article <ZI******************@news2.e.nsc.no>, Tor Rustad wrote:
"Nils Weller" <me@privacy.net> 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>

Nov 14 '05 #11
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.

Nov 14 '05 #12
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."

Nov 14 '05 #13
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!
Nov 14 '05 #14
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.
Nov 14 '05 #15
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
Nov 14 '05 #16
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
Nov 14 '05 #17
"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>
Nov 14 '05 #18
"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>

Nov 14 '05 #19

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: boy | last post by:
Hi all, I have created a simple template class as follow, but i encountered memory leakage on the base.Render(writer). Have all you of encountered the same problem? using System; using...
2
by: Sambucus | last post by:
Hi group! I am using C++ and java with JNI to get some text in a RICHEDIT to my java program. I do so by accessing a C++ method every second. It all works fine except that it leaks memory every...
0
by: csgraham74 | last post by:
Hi Folks, I have inherited an application that references dll's using biztalk. All my dlls work correctly apart from two of them in that they continue to grow in memory size on the server and do...
7
by: andylcx | last post by:
hi all: I have a code like below, is there any serious memory leakage in my code. I am confusion now but no idea how to fix it. In the member function of class A, I create a new object of class B...
1
by: GaŽl | last post by:
Hi everybody! I have a really big problem with ASP.NET application. I noticed that the w3wp.exe memory size, increase with the time and the use of my website. When it raise a certain value, w3wp...
0
by: kiran kumar | last post by:
Hi All, I am working on embedded python on C these days. I feel there is a memory leakage in this code. I have used our own memory pool and all the python code will use the heap from this memory...
7
by: madhawi | last post by:
please give me the solution for the problem of memory leakage.
3
by: Godzilla | last post by:
Hello, I have a program that create and pop an object off a queue, but it is experiencing some memory leakage. I have been unable to detect where the memory leakage occur. The strange thing is...
11
by: prpradip | last post by:
I have an ImageList (_imageList). In _imageList I have put large numbers of Icons. Now what I need is to get Handle of all Icons that I put in _imageList, so that I can destroy (DestoryIcon) them...
2
by: DJRhino | last post by:
Was curious if anyone else was having this same issue or not.... I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM) The start time is equivalent to 19:00 (7PM) in Central...
2
by: giovanniandrean | last post by:
The energy model is structured as follows and uses excel sheets to give input data: 1-Utility.py contains all the functions needed to calculate the variables and other minor things (mentions...
4
NeoPa
by: NeoPa | last post by:
Hello everyone. I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report). I know it can be done by selecting :...
3
NeoPa
by: NeoPa | last post by:
Introduction For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
1
by: Teri B | last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course. 0ne-to-many. One course many roles. Then I created a report based on the Course form and...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 1 Nov 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM) Please note that the UK and Europe revert to winter time on...
0
NeoPa
by: NeoPa | last post by:
Introduction For this article I'll be focusing on the Report (clsReport) class. This simply handles making the calling Form invisible until all of the Reports opened by it have been closed, when it...
0
isladogs
by: isladogs | last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, Mike...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.