By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,949 Members | 950 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,949 IT Pros & Developers. It's quick & easy.

using return in main to check memory leaks

P: n/a
Hello,
I'm thinking that it would be a good idea to start using the return
code for main() to return the amount of memory still allocated (which
would hopefully be zero) to ensure all memory has been freed.

What would be the best way to do this? Is this kind of thing common
practice?

I would guess that perhaps a global long variable would be used, and
malloc (free) would add (subtract) to this variable.

Cheers, Matt

Apr 10 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
"ballpointpenthief" <Ma*************@gmail.com> wrote:
I'm thinking that it would be a good idea to start using the return
code for main() to return the amount of memory still allocated (which
would hopefully be zero) to ensure all memory has been freed.


I think this would be, depending on how you mean that, either useless
and unimplementable, or a great way to break a good deal of existing
programs.

Richard
Apr 10 '06 #2

P: n/a

Richard Bos wrote:
"ballpointpenthief" <Ma*************@gmail.com> wrote:
I'm thinking that it would be a good idea to start using the return
code for main() to return the amount of memory still allocated (which
would hopefully be zero) to ensure all memory has been freed.


I think this would be, depending on how you mean that, either useless
and unimplementable, or a great way to break a good deal of existing
programs.

Richard


OK, so you are saying that if this practice was widespread it would be
a bad idea. I shall accept that as true.

I'm still new to C, and programming full stop, and if I could return
some variable from main() instead of a constant while I am working on
one of my programmes, I would feel a lot happier about my ability to
free memory.

Do you agree that this would be good practice and how should I approach
this?

Apr 10 '06 #3

P: n/a
On 2006-04-10, ballpointpenthief <Ma*************@gmail.com> wrote:
Hello,
I'm thinking that it would be a good idea to start using the return
code for main() to return the amount of memory still allocated (which
would hopefully be zero) to ensure all memory has been freed.

What would be the best way to do this? Is this kind of thing common
practice?
Tracking memory is, although I've never heard of returning the unfreed
count from main.
I would guess that perhaps a global long variable would be used, and
malloc (free) would add (subtract) to this variable.


The idea's good, but the problem is knowing how much to subtract in
free. One way of doing this is to overallocate the block by a sensibly
aligned offset in a modified malloc and store the length of the block
before the actual block, where the modified free can find it.
Apr 10 '06 #4

P: n/a


ballpointpenthief wrote On 04/10/06 11:04,:
Richard Bos wrote:
"ballpointpenthief" <Ma*************@gmail.com> wrote:

I'm thinking that it would be a good idea to start using the return
code for main() to return the amount of memory still allocated (which
would hopefully be zero) to ensure all memory has been freed.


I think this would be, depending on how you mean that, either useless
and unimplementable, or a great way to break a good deal of existing
programs.

Richard

OK, so you are saying that if this practice was widespread it would be
a bad idea. I shall accept that as true.

I'm still new to C, and programming full stop, and if I could return
some variable from main() instead of a constant while I am working on
one of my programmes, I would feel a lot happier about my ability to
free memory.

Do you agree that this would be good practice and how should I approach
this?


No. You're trying to co-opt a mechanism designed for
one purpose and twist it to an entirely unrelated purpose.
After all, what's special about the amount of un-freed
memory? Why not return the number of un-closed files, or
the maximum function call depth, or the number of strlen()
calls that returned zero? All these and more might be of
interest in some circumstances, and it makes little sense
to try to cram them all through the same needle's eye.

Note, also, that when you return from main() or call
exit() your program is not necessarily finished yet and the
amount of un-freed memory at the moment main() returns may
not be the same as the amount when execution finally ceases.
Here's a simple (and stupid) example:

#include <stdlib.h>

static void gobble(void) {
void *p;
while ((p = malloc(30000)) != NULL)
;
}

int main(void) {
atexit(gobble);
return 0; /* no un-freed memory */
}

.... and its converse:

#include <stdlib.h>
static char *bigarray = NULL;

static void cleanup(void) {
free(bigarray);
}

int main(void) {
atexit(cleanup);
bigarray = malloc(1000);
return (bigarray == NULL) ? 0 : 1000;
}

You may well look at these and say "I would never
do anything so silly," but a more careful look suggests
that the second example really isn't so silly after all.
For example, do you suppose stdin, stdout, and stderr
might own buffer areas they obtained from malloc()? How
about the internal operation of atexit(): might it use
malloc() to get space to store the function pointer?
All of a sudden you find you need to distinguish between
"your" allocated memory and "somebody else's" allocated
memory, and not long after you'll discover that there
are several "somebody elses" in a typical program.

Vigilance in managing memory is a Good Thing, but
this particular idea is not.

--
Er*********@sun.com

Apr 10 '06 #5

P: n/a
"ballpointpenthief" <Ma*************@gmail.com> writes:
I'm thinking that it would be a good idea to start using the return
code for main() to return the amount of memory still allocated (which
would hopefully be zero) to ensure all memory has been freed.

What would be the best way to do this? Is this kind of thing common
practice?

I would guess that perhaps a global long variable would be used, and
malloc (free) would add (subtract) to this variable.


it's a good idea during development (sometimes), which is why there
are debug malloc libraries that do just that if you ask them. look at
valgrind or electric fence (i'm pretty sure they do that, it's been a
while since i tried them) or else google for 'debug malloc library'
and read the docs.

--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com
Apr 10 '06 #6

P: n/a
On 2006-04-10, Burton Samograd <kr**********@gmail.com> wrote:
"ballpointpenthief" <Ma*************@gmail.com> writes:
I'm thinking that it would be a good idea to start using the return
code for main() to return the amount of memory still allocated (which
would hopefully be zero) to ensure all memory has been freed.


[snip]

<OT> it's a good idea during development (sometimes), which is why there
are debug malloc libraries that do just that if you ask them. look at
valgrind or electric fence (i'm pretty sure they do that, it's been a
while since i tried them)


Valgrind can do that, not electric fence. That's for something else--
catching out-of-bounds memory accesses.
</OT>
Apr 10 '06 #7

P: n/a
"ballpointpenthief" <Ma*************@gmail.com> writes:
I'm thinking that it would be a good idea to start using the return
code for main() to return the amount of memory still allocated (which
would hopefully be zero) to ensure all memory has been freed.

What would be the best way to do this? Is this kind of thing common
practice?


The only portable values you can return from main() are 0,
EXIT_SUCCESS, and EXIT_FAILURE (EXIT_SUCCESS is typically equal to 0).

Most systems support other values, but Unix-like systems, for example,
map all results to the range 0..255.

--
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.
Apr 10 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.