Do memory allocations need to be freeed every time?

[Ravindra.B]

I have declared a global variable which is array of pointers and
allocated memory for each array variable by using malloc. Some thing
similar to below...

static char *arr[10];

main()
{
int i;

for(i = 0; i < 10; i++)
arr = malloc(sizeof(char));

……..

}

Is freeing the allocated memory is really required every time, for a
program like this as freeing doesn’t bring in any change w.r.t
memory space (or) will it become a memleak some where down the line if
it is not freeed?

Thanx,
Ravindra. Bhadramraju

 

[vippstar]

I have declared a global variable which is array of pointers and
allocated memory for each array variable by using malloc. Some thing
similar to below...

Is freeing the allocated memory is really required every time, for a

Yes. *Every* malloc pointer must be freed.

 

[den2k]

Is freeing the allocated memory is really required every time, for a
program like this as freeing doesn’t bring in any change w.r.t
memory space (or) will it become a memleak some where down the line if
it is not freeed?

Thanx,
Ravindra. Bhadramraju

Let's say that it is a good practice. It is reasonable to think that
this piece of code will be used somewhere in a bigger application,
which may be executed continuosly for a lot of time whitout being
closed, and this may lead to mem leak.

Besides not every OS frees memory after the execution of a program and
many OSs may not free it due to an abnormal termination, so it's
always better to explicitly free memory by yourself.

 

[Chris Dollin]

Yes. *Every* malloc pointer must be freed.

/Should/, not /must/.

(and " ... eventually".)

 

[jacob navia]

I have declared a global variable which is array of pointers and
allocated memory for each array variable by using malloc. Some thing
similar to below...

static char *arr[10];

main()
{
int i;

for(i = 0; i < 10; i++)
arr = malloc(sizeof(char));

……..

}

Is freeing the allocated memory is really required every time, for a
program like this as freeing doesn’t bring in any change w.r.t
memory space (or) will it become a memleak some where down the line if
it is not freeed?

Thanx,
Ravindra. Bhadramraju

You can avoid the error prone usage of free by using a garbage
collector. This software will free automatically the allocated
memory for you when it notices that is no longer used.

Good compilers provide this facility in their standard distribution.

 

[Ravindra.B]

I have declared a global variable which is array of pointers and
allocated memory for each array variable by using malloc.  Some thing
similar to below...

static char *arr[10];

main()
{
int i;

for(i = 0; i < 10; i++)
arr = malloc(sizeof(char));

……..

}

Is freeing the allocated memory is really required every time, for a
program like this as freeing doesn’t  bring in  any change w.r.t
memory space (or) will it become a memleak some where down the line if
it is not freeed?

Thanx,
Ravindra. Bhadramraju

You can avoid the error prone usage of free by using a garbage
collector. This software will free automatically the allocated
memory for you when it notices that is no longer used.

Good compilers provide this facility in their standard distribution.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32- Hide quoted text -

- Show quoted text -

That sounds interesting.

Can you tell me what are all the compilers that support it and how to
configure the same.

Thanx,
Ravindra.Bhadramraju

 

[den2k]

Good compilers provide this facility in their standard distribution.

IMHO the better compiler stays in the middle of our ears, so there
must be the GC.. it is better to free manually, so you do know exactly
how your code behaves.

 

[vippstar]

I have declared a global variable which is array of pointers and
allocated memory for each array variable by using malloc. Some thing
similar to below...
static char *arr[10];
main()
{
int i;
for(i = 0; i < 10; i++)
arr = malloc(sizeof(char));
……..
}
Is freeing the allocated memory is really required every time, for a
program like this as freeing doesn’t bring in any change w.r.t
memory space (or) will it become a memleak some where down the line if
it is not freeed?
Thanx,
Ravindra. Bhadramraju

You can avoid the error prone usage of free by using a garbage
collector. This software will free automatically the allocated
memory for you when it notices that is no longer used.

Good compilers provide this facility in their standard distribution.

- Show quoted text -

That sounds interesting.

Can you tell me what are all the compilers that support it and how to
configure the same.

Do not quote sig blocks.
No, it's not interesting. These garbage collectors are error prone,
free() is not.
I've never heard of a good C compiler providing a GC.
They are also off-topic to discuss here. I, and others have, already
answered you:
You *must* free() allocated memory.
(Or, with Mr Dollins correction: you should, eventually)

 

[viza]

Hi

Is freeing the allocated memory is really required every time, for a
program like this as freeing doesn’t bring in any change w.r.t memory
space (or) will it become a memleak some where down the line if it is
not freeed?

To avoid memory leaks, for each and every time you call malloc(), you
must call free() exactly once with the same pointer that was returned.

The only exceptions to this are:

1) if the call to malloc() returned NULL
2) if you are about to immediately terminate the program anyway*

* see
http://groups.google.co.uk/group/comp.lang.c/browse_thread/thread/
be39423f62c88e04/a8e1101586394d42

HTH
viza

 

[Richard Bos]

To avoid memory leaks, for each and every time you call malloc(), you
must call free() exactly once with the same pointer that was returned.

The only exceptions to this are:

1) if the call to malloc() returned NULL
2) if you are about to immediately terminate the program anyway*

And even in those cases, you _may_ call free(), and it is often
considered good style (and particularly in the first case, can simplify
your code) if you do.

Richard

 

[jacob navia]

That sounds interesting.

Can you tell me what are all the compilers that support it and how to
configure the same.

The most popular garbage collector is Boehm's GC. It works with gcc
(you need to install it separatedly).

lcc-win (http://www.cs.virginia.edu/~lcc-win32) features a GC in
the standard distribution.

Note that if you download lcc-win, you can use gc.dll (32 bits
only) with another compiler if you wish. That would make it
possible to use a GC with ANY windows compiler.

Boehm's GC runs in almost all serious operating systems, wchich
includes several varints of HP unix, linux, MAC os, etc.

lcc-win has ported the GC to 64 bit windows and will be
distributed with the 64 bit version of lcc-win.

 

[santosh]

[ ... ]

Don't retain signatures unless you are discussing them. Signature blocks
are text following a "\n-- \n" sequence.

That sounds interesting.

Can you tell me what are all the compilers that support it and how to
configure the same.

Be aware that Garbage Collection is *not* a part of ISO C. If you want
your code to be portable to as many implementations as feasible, then a
Garbage Collector is likely to be a hindrance than help. Also Garbage
Collectors are not quite deterministic - they may very rarely free
memory in use or more commonly, fail to free memory that ought to be
freed. The might also not be suitable for program that demand realtime
response to events.

Having said all this, if you still want to tie your code to a GC, then
one of the better ones is the Boehm GC.

<http://www.hpl.hp.com/personal/Hans_Boehm/gc/>

 

[santosh]

I have declared a global variable which is array of pointers and
allocated memory for each array variable by using malloc. Some thing
similar to below...

static char *arr[10];

main()
{
int i;

for(i = 0; i < 10; i++)
arr = malloc(sizeof(char));

??..

}

You might want to use a local array instead of a global one to reduce
maintenance headaches in the future. A local array inside main is
almost as long-lived as a file scope or static object, but may be
easier to manage in multi-threaded environment.

Also you might find that allocating memory just before needed and
deallocating it after you have finished may be an easier strategy than
allocating all the memory in one place and freeing it all at once in
another place.

Is freeing the allocated memory is really required every time, for a
program like this as freeing doesn?t bring in any change w.r.t
memory space (or) will it become a memleak some where down the line if
it is not freeed?

Deallocating unused memory is vitally important for daemon and server
programs. Even for a program that will do a short amount of work and
exit fairly quickly you might still want to get into the habit of
allocating memory when needed and scrupulously deallocating them when
you are done. This will be of immense help when you progress to large,
long lived programs, system programs etc.

 

[Linonut]

* (e-mail address removed) peremptorily fired off this memo:

You *must* free() allocated memory.
(Or, with Mr Dollins correction: you should, eventually)

But if you don't, the OS may do it for you -- catastrophically <grin>.

 

[santosh]

using it. It probably wouldn't matter (its just 10 bytes) on modern
systems if you were to do free just before program quits (since OS
would clean that mess for you), but for programs that run
continuously (like service daemons), memory leaks like this might
eventually bring system to its knees.

if malloc() function is like that is in the book K&RII there is the
problem that it use more memory that should be sufficient, because
seems to me that malloc() increase memory only [never decrease it if
see the OS]: the memory should be free only at the end of program and
never first.

Some implementations of malloc do behave this because of system
constraints, but many implementations of malloc request memory on a
page by page basis and return freed pages as soon as you free them. You
must examine your implementation to find out how your malloc is
written. From the point of view of a standard C program, memory that is
freed is "made available for further allocation". How, when, and to
whom are questions that the standard leaves up to the implementations
to answer.

 

[gw7rib]

I have declared a global variable which is array of pointers and
allocated memory for each array variable by using malloc.  Some thing
similar to below...

static char *arr[10];

main()
{
int i;

for(i = 0; i < 10; i++)
arr = malloc(sizeof(char));

……..

}

Is freeing the allocated memory is really required every time, for a
program like this as freeing doesn’t  bring in  any change w.r.t
memory space (or) will it become a memleak some where down the line if
it is not freeed?

There's one point that people so far don't seem to have pointed out,
which may or may not be what you were asking.

Suppose your program uses, say, a buffer that can hold 10 chars, and
then, after that has finished, needs another buffer also of 10 chars.
You don't necessarily need to free the first buffer and then allocate
a new one - you could just keep the same one.

For example, the following:

buff = malloc(10);
/* first bit of code here, which uses buff */
free(buff);

/* second bit of code here, which doesn't use buff */

buff = malloc(10);
/* third bit of code here, which uses buff */
free(buff);

... could be replaced with the following:

buff = malloc(10);
/* first bit of code here, which uses buff */

/* second bit of code here, which doesn't use buff */

/* third bit of code here, which uses buff */
free(buff);

This would keep the memory allocated during the second bit of code,
meaning that your program uses more space than it needs to, but this
might not be a problem. It saves the expense of having to free the
memory and having to malloc another buffer. You have to decide whether
this is a worthwhile compromise.

You may think you need to malloc a new buffer to "clear" it, but this
is not the case - malloc does not (usually) clear the space it
allocates. So you may be able to reduce the number of mallocs and
frees that your program needs to do. You just have to make sure that
each buffer is big enough for what you will be using it for, and that
you don't overwrite any data that you still need.

Hope that helps.
Paul.

 

[Flash Gordon]

jacob navia wrote, On 19/06/08 12:11:
How to use a non-standard library is not topical here. It will depend on
your compiler/OS and maybe other things and so would be appropriate in a
group dedicated to your implementation or maybe mailing lists for
Boehm's GC.

The most popular garbage collector is Boehm's GC. It works with gcc
(you need to install it separatedly).

You stated in your previous post, "Good compilers provide this facility
in their standard distribution."

Installed separately is *not* "in their standard distribution". I also
believe that MS do not ship it as part of their implementation nor do
Intel and a lot of people consider one or both of those to be good
compilers.

Also are you sure it is available for *all* targets supported by gcc?
For a start I see no mention of lots of the systems that gcc supports.

lcc-win (http://www.cs.virginia.edu/~lcc-win32) features a GC in
the standard distribution.

Note that if you download lcc-win, you can use gc.dll (32 bits
only) with another compiler if you wish. That would make it
possible to use a GC with ANY windows compiler.
So?

Boehm's GC runs in almost all serious operating systems,

I saw no mention of, to take a few, z/OS, z/TPF or vxWorks to name just
three serious operating systems with completely different markets.

wchich
includes several varints of HP unix, linux, MAC os, etc.

This is not what the web site says. It says:
| The collector is not completely portable, but the distribution
| includes ports to most standard PC and UNIX/Linux platforms. The
| collector should work on Linux, *BSD, recent Windows versions, MacOS
| X, HP/UX, Solaris, Tru64, Irix and a few other operating systems. Some
| ports are more polished than others.

Note the last part, "some ports are more polished than others," which
implies there are still problems with some of the ports it lists.

lcc-win has ported the GC to 64 bit windows and will be
distributed with the 64 bit version of lcc-win.

So? The worls of serious OSs is much larger than that.