Memory Leak Programs

[c language]

Hello all,

I am using 'Valgrind' to fix the memory leaks of my programs. I am
looking for other programs to see how they are detecting the problems.
Does any of you have experience in working with othere programs?
Please let me know if you feel the program that you are working with is
a good tool to detect the memory leaks.

Thanks,
Mohsen

[Frederick Gotham]

c language:

I am using 'Valgrind' to fix the memory leaks of my programs. I am
looking for other programs to see how they are detecting the problems.
Does any of you have experience in working with othere programs?
Please let me know if you feel the program that you are working with is
a good tool to detect the memory leaks.

Here's an idea. . .

Hijack "malloc" and "free".

Every time memory is allocated, keep a note of it and record the source file
and line number. Every time memory is deallocated, take note of its
deallocation.

When the program ends, print out all the allocations which didn't have a
corresponding deallocation.

Better yet, pay attention when you're programming.

--

Frederick Gotham

[Walter Roberson]

In article <11**********************@f16g2000cwb.googlegroups .com>,
c language <ja*******@gmail.comwrote:

>I am using 'Valgrind' to fix the memory leaks of my programs. I am
looking for other programs to see how they are detecting the problems.
Does any of you have experience in working with othere programs?
Please let me know if you feel the program that you are working with is
a good tool to detect the memory leaks.

The commercial program "Purify" can be very useful in tracking
memory leaks and subscript errors and several other kinds of
problems. It isn't cheap, and it isn't something you need every day,
but when you need it, it can really save your fundament.

Purify is from the Rational line, now owned by IBM.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[c language]

Frederick Gotham wrote:

c language:

I am using 'Valgrind' to fix the memory leaks of my programs. I am
looking for other programs to see how they are detecting the problems.
Does any of you have experience in working with othere programs?
Please let me know if you feel the program that you are working with is
a good tool to detect the memory leaks.

Here's an idea. . .

Hijack "malloc" and "free".

Every time memory is allocated, keep a note of it and record the source file
and line number. Every time memory is deallocated, take note of its
deallocation.

I don't know how to do this

>
When the program ends, print out all the allocations which didn't have a
corresponding deallocation.

I don't know how to do this

>
Better yet, pay attention when you're programming.

--

Frederick Gotham

[Bill Pursell]

c language wrote:

Frederick Gotham wrote:

c language:

I am using 'Valgrind' to fix the memory leaks of my programs. I am
looking for other programs to see how they are detecting the problems.
Does any of you have experience in working with othere programs?
Please let me know if you feel the program that you are working with is
a good tool to detect the memory leaks.

Hijack "malloc" and "free".

Every time memory is allocated, keep a note of it and record the source file
and line number. Every time memory is deallocated, take note of its
deallocation.

I don't know how to do this

If you are using a GNU/Linux system, you get something
similar if you begin your program with mcheck():

#include <mcheck.h>
int main(void)
{
mcheck(NULL);
...
}

This causes libc to use a malloc that does checking for you,
and aborts the program if it detects an error.

Also, read up on Electric Fence.

--
Bill Pursell

[Frederick Gotham]

c language:

>Every time memory is allocated, keep a note of it and record the source
file and line number. Every time memory is deallocated, take note of
its deallocation.

I don't know how to do this

>When the program ends, print out all the allocations which didn't have
a corresponding deallocation.

I don't know how to do this

If you put the following in a header file, and include it _after_ all
Standard headers have been included, then you might have some joy. Better
yet, you could find your compiler's <stdlib.hfile and change it.

(Unchecked code, likely to contain a bug or two.)

#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>

typedef struct AllocInfo {
void *p;
char const *filename;
unsigned line;
} AllocInfo;

AllocInfo ai_list[512]; /* Allows for 512 separate allocations. */
AllocInfo *ai_current = ai_list;

void CheckFreed(void);

void *const MyMalloc(size_t const len,char const *const file,
unsigned const line)
{
static int first_time = 1;
if (first_time) { atexit(CheckFreed); first_time = 0; }

ai_current->filename = file;
ai_current->line = line;

return ai_current++->p = malloc(len);
}

void MyFree(void *const p)
{
AllocInfo *pai = ai_current;

for(;;--pai) if (p == pai->p) { free(p); pai->p = 0; return; }
}

void ReportLeak(AllocInfo const *const);

void CheckFreed(void)
{
AllocInfo const *pai = ai_list;

for(;;++pai)
{
if (pai->p) ReportLeak(pai);

if (pai == ai_current) return;
}
}

void ReportLeak(AllocInfo const *const pai)
{
printf("Memory leak allocated at:\n %s Line %u\n",
pai->filename, pai->line);
}

#define malloc(len) MyMalloc(len, __FILE__, __LINE__)
#define free(p) MyFree(p)

int main(void)
{
void *const a = malloc(5);
void *const b = malloc(5);
void *const c = malloc(5);
void *const d = malloc(5);
void *const e = malloc(5);
void *const f = malloc(5);

free(b); free(d); free(f);

return 0;
}

--

Frederick Gotham

[Keith Thompson]

Frederick Gotham <fg*******@SPAM.comwrites:

c language:

>>Every time memory is allocated, keep a note of it and record the source
file and line number. Every time memory is deallocated, take note of
its deallocation.

I don't know how to do this

>>When the program ends, print out all the allocations which didn't have
a corresponding deallocation.

I don't know how to do this

If you put the following in a header file, and include it _after_ all
Standard headers have been included, then you might have some joy. Better
yet, you could find your compiler's <stdlib.hfile and change it.

Changing your implementation's <stdio.hcould be very dangerous;
don't consider doing it unless you know *exactly* what you're doing.

(Unchecked code, likely to contain a bug or two.)

#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>

[snip]

#define malloc(len) MyMalloc(len, __FILE__, __LINE__)
#define free(p) MyFree(p)

[snip]

Be sure to #undef malloc and free first; they can both be defined as
macros in <stdlib.h>.

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

[EKB]

c language wrote:

Frederick Gotham wrote:

c language:

I am using 'Valgrind' to fix the memory leaks of my programs. I am
looking for other programs to see how they are detecting the problems.
Does any of you have experience in working with othere programs?
Please let me know if you feel the program that you are working with is
a good tool to detect the memory leaks.

Here's an idea. . .

Hijack "malloc" and "free".

Every time memory is allocated, keep a note of it and record the source file
and line number. Every time memory is deallocated, take note of its
deallocation.

I don't know how to do this

When the program ends, print out all the allocations which didn't have a
corresponding deallocation.

I don't know how to do this

Better yet, pay attention when you're programming.

--

Frederick Gotham

I've used Walter Bright's MEM package, which uses a similar approach
(although he introduces new functions/macros to replace malloc & free,
rather than "hijacking" them - it takes a bit of work to replace malloc
with the new names, but not much). The code is available on the C
snippets page:

http://c.snippets.org/browser.php

Eric

[Richard Heathfield]

Keith Thompson said:

<snip>

Changing your implementation's [system headers] could be very dangerous;
don't consider doing it unless you know *exactly* what you're doing.

If he knew exactly what he were doing, he would not be suggesting changing
system headers (least of all for something as trivial as memory tracking).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Frederick Gotham]

Keith Thompson:

Be sure to #undef malloc and free first; they can both be defined as
macros in <stdlib.h>.

Just out of curiosity, is that necessary? I know it would be the prefereable
thing to do (if only to suppress compiler warnings), but is it necessitated
by the Standard? The following source file only gives me a warning with gcc:

#define A 5
#define A 6

--

Frederick Gotham

[Frederick Gotham]

Richard Heathfield:

>Changing your implementation's [system headers] could be very dangerous;
don't consider doing it unless you know *exactly* what you're doing.

If he knew exactly what he were doing, he would not be suggesting

changing

system headers (least of all for something as trivial as memory

tracking).
If you had a few dozen source files which made use of "malloc" and "free",
then it would be a lot handier to play around with <stdlib.hthan to go
through each of them and add an inclusion directive.

It's quite trivial on my own computer:

(1) Find the directory where the compiler is installed.
(2) Look for a directory entitled something like "include".
(3) Look for "stdlib.h".
(4) Make a copy of it.
(5) Alter the original.

Of course, I realise that the Standard does not necessitate that there be a
file called <stdlib.h>, but this psuedosolution would work for the majority
of implementations, I think.

Or do I just not no what I'm doing -- if so, please enlighten me.

--

Frederick Gotham

[Richard Heathfield]

Frederick Gotham said:

Richard Heathfield:

>>Changing your implementation's [system headers] could be very dangerous;
don't consider doing it unless you know *exactly* what you're doing.

If he knew exactly what he were doing, he would not be suggesting

changing

>system headers (least of all for something as trivial as memory

tracking).
If you had a few dozen source files which made use of "malloc" and "free",
then it would be a lot handier to play around with <stdlib.hthan to go
through each of them and add an inclusion directive.

This advice is extremely unsound. I'm not interested in having a prolonged
dispute with you (see below), but I strongly recommend that people do not
mess with their implementation's headers. It is an extraordinarily unwise
thing to do.

It's quite trivial on my own computer:

The ease with which stupid things can be done does not make them any less
stupid.

Or do I just not no what I'm doing --

Correct - you do not know what you're doing.

if so, please enlighten me.

You have proved impossible to enlighten, and I am not one to continue to
attempt the impossible for very long. If you want me to enlighten you in
the future, first be enlightened by what I have said in the past.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Frederick Gotham]

Richard Heathfield:

You have proved impossible to enlighten, and I am not one to continue to
attempt the impossible for very long. If you want me to enlighten you in
the future, first be enlightened by what I have said in the past.

Am I supposed to view as a guru the man who cannot withhold snide remarks,
and who must present a facade of hostile assertiveness to even begin to
appear to get anywhere in an argument? Your pretension perpetuates your
inability to present yourself as a pleasant, rational person.

Perhaps you should read back over your ever-so-public correspondence with
Jacob Navia, and have a think about whether you're proud of your repugnant
behaviour. Maybe it'd help if you had a few drinks beforehand, I find it
helps to maintain objectiveness.

Have fun in your little playpen that is comp.lang.c.

--

Frederick Gotham

[Richard Heathfield]

Frederick Gotham said:

Richard Heathfield:

>You have proved impossible to enlighten, and I am not one to continue to
attempt the impossible for very long. If you want me to enlighten you in
the future, first be enlightened by what I have said in the past.

Am I supposed to view as a guru the man who cannot withhold snide remarks,
and who must present a facade of hostile assertiveness to even begin to
appear to get anywhere in an argument?

I don't see that you have any cause to regard yourself as a guru. The rest
of your self-description, however, seems reasonably accurate, so I cannot
really take issue with it.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Gordon Burditt]

>>Changing your implementation's [system headers] could be very dangerous;

>>don't consider doing it unless you know *exactly* what you're doing.

If he knew exactly what he were doing, he would not be suggesting

changing

>system headers (least of all for something as trivial as memory

tracking).
If you had a few dozen source files which made use of "malloc" and "free",
then it would be a lot handier to play around with <stdlib.hthan to go
through each of them and add an inclusion directive.

Would it then be a lot "handier" to compile *EVERYTHING* you have
or will eventually have in source code and test it to make sure it
still works with the modifications?

Would it be "handier" to re-incorporate those changes every time you
upgrade the compiler?

Would it be "handier" to explain these changes to everyone you give
your source code to so they can compile it?

Would it be "handier" to discover that you can no longer compile the
C library (you sound like you'd like to change that, too, and you
might even have a legitimate reason to do that), or that when you
do, it no longer works? I especially expect trouble compiling the
real malloc() and free() functions.

Even if you don't need portability in general, if your system is, say,
Windows XP service pack 2.38361 with DevC++ 8.32.21.37547.21832.2847.243
it would be nice if your stuff compiled on another system exactly like that.

>It's quite trivial on my own computer:

(1) Find the directory where the compiler is installed.
(2) Look for a directory entitled something like "include".
(3) Look for "stdlib.h".
(4) Make a copy of it.
(5) Alter the original.

Of course, I realise that the Standard does not necessitate that there be a
file called <stdlib.h>, but this psuedosolution would work for the majority
of implementations, I think.

Or do I just not no what I'm doing -- if so, please enlighten me.

You will rapidly get to a point where your modifications cannot compile
everything you need to compile, and you have to have several sets of
include files.

[Keith Thompson]

Frederick Gotham <fg*******@SPAM.comwrites:

Richard Heathfield:

>>Changing your implementation's [system headers] could be very dangerous;
don't consider doing it unless you know *exactly* what you're doing.

If he knew exactly what he were doing, he would not be suggesting
changing system headers (least of all for something as trivial as
memory tracking).

If you had a few dozen source files which made use of "malloc" and "free",
then it would be a lot handier to play around with <stdlib.hthan to go
through each of them and add an inclusion directive.

[...]

It may be convenient; that doesn't mean it's a good idea.

An implementation's system headers, even assuming they're available as
files, can depend on any arbitrary compiler features; they don't have
to be written in standard C. If you attempt to modify them, you risk
violating some assumption that the author(s) may have made, an
assumption that they're under absolutely no obligation to share with
you. And, of course, your changes will apply to any programs you
compile using those same headers. If you're the only user on the
system, you're very likely to shoot yourself in the foot; if you share
the system with other developers, *they'll* shoot you in the foot.

I would not even consider editing system headers except *maybe* as a
desparate last resort. Any solution based on doing this would be
non-reproducible (I can't expect anyone else to mess around with
*their* system headers). And in this case (replacing malloc and
free), it's not even necessary; you can do it in your own code with
only a little extra effort.

Even if you're such an expert that you're able to do this kind of
thing without risk, advising other mere mortals to do so is extremely
ill-advised.

BTW, the question you asked elsethread about macro redefinition is
answered in C99 6.10.3p2.

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

[Ian Collins]

Frederick Gotham wrote:

If you had a few dozen source files which made use of "malloc" and "free",
then it would be a lot handier to play around with <stdlib.hthan to go
through each of them and add an inclusion directive.

It's quite trivial on my own computer:

(1) Find the directory where the compiler is installed.
(2) Look for a directory entitled something like "include".
(3) Look for "stdlib.h".
(4) Make a copy of it.
(5) Alter the original.

Which you have to do each time you upgrade or patch. Any of my systems
would require root access to the server to make these changes, which I
wouldn't grant.

<possibly OT>
The times I've wanted to replace the system malloc/free, I've done just
that: provide my own malloc and free functions, which do what I want
them to do and call the OS specific allocate and free routines to manage
memory.

This only works if malloc and free can be replaced without causing
duplicate symbol errors, which implies some form of week symbol support
in the linker. So far, I've been lucky!
</possibly OT>

--
Ian Collins.

[Mark McIntyre]

On Sun, 05 Nov 2006 16:49:06 GMT, in comp.lang.c , Frederick Gotham
<fg*******@SPAM.comwrote:

>Richard Heathfield:

>You have proved impossible to enlighten, and I am not one to continue to
attempt the impossible for very long. If you want me to enlighten you in
the future, first be enlightened by what I have said in the past.

Am I supposed to view as a guru the man who cannot withhold snide remarks,

No, you're supposed to actually read for comprehension. Why should
anyone waste time trying to enlighten you now, when you've already
shown yourself largely incapable of enlightenment?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Sun, 05 Nov 2006 16:07:38 GMT, in comp.lang.c , Frederick Gotham
<fg*******@SPAM.comwrote:

>Richard Heathfield:

>>Changing your implementation's [system headers] could be very dangerous;
don't consider doing it unless you know *exactly* what you're doing.

If he knew exactly what he were doing, he would not be suggesting

changing

>system headers (least of all for something as trivial as memory

tracking).
If you had a few dozen source files which made use of "malloc" and "free",
then it would be a lot handier to play around with <stdlib.hthan to go
through each of them and add an inclusion directive.

Handier for -you-.

The poor bugger who has to maintain your code would however be
screwed, because he's not using your computer, and you've long since
left the firm.
And the poor sod who has to migrate your code to the next version of
the compiler is also in trouble.
And the guy who has to migrate it to a different platform...

Seriously, mucking with the sytem headers is a very bad idea.

>Or do I just not no what I'm doing

You really don't know what you're doing.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Frederick Gotham]

In response to those who have replied regarding modification of <stdlib.h>:

I thought the OP had the source code for a program which had a memory
leak, and I thought he wanted to find the memory leak. I thought code which
hijacked "malloc" and "free" might help him find the memory leak. I didn't
mean for the code to be used indefinitely, but rather a "once off" sort of
thing.

Of course, the Standard doesn't necessitate that an implementation use
straightforward files to represent standard headers, but fortunately a lot of
implementations do, so it may have been handy in these circumstances to alter
<stdlib.h>.

I have to admit though that I haven't got much experience in the whole
"memory leak" game, as I read back over my code, and a "malloc" without a
corresponding "free" would stick out like a sore thumb to me.

--

Frederick Gotham

[Ian Collins]

Frederick Gotham wrote:

In response to those who have replied regarding modification of <stdlib.h>:

I thought the OP had the source code for a program which had a memory
leak, and I thought he wanted to find the memory leak. I thought code which
hijacked "malloc" and "free" might help him find the memory leak. I didn't
mean for the code to be used indefinitely, but rather a "once off" sort of
thing.

Of course, the Standard doesn't necessitate that an implementation use
straightforward files to represent standard headers, but fortunately a lot of
implementations do, so it may have been handy in these circumstances to alter
<stdlib.h>.

I have to admit though that I haven't got much experience in the whole
"memory leak" game, as I read back over my code, and a "malloc" without a
corresponding "free" would stick out like a sore thumb to me.

That's fine until you start allocating pointers (whether naked or
hidden) in one function and freeing it some arbitrary time later in another!

--
Ian Collins.

[Richard Bos]

Frederick Gotham <fg*******@SPAM.comwrote:

Richard Heathfield:

Changing your implementation's [system headers] could be very dangerous;
don't consider doing it unless you know *exactly* what you're doing.

If he knew exactly what he were doing, he would not be suggesting

changing

system headers (least of all for something as trivial as memory

tracking).
If you had a few dozen source files which made use of "malloc" and "free",
then it would be a lot handier to play around with <stdlib.hthan to go
through each of them and add an inclusion directive.

It's quite trivial on my own computer:

(1) Find the directory where the compiler is installed.
(2) Look for a directory entitled something like "include".
(3) Look for "stdlib.h".
(4) Make a copy of it.
(5) Alter the original.

This is always the wrong way to go about it. As you say, there may not
even be a file called "stdlib.h", but that's rare; but this is
dangerously wrong even when there is. The proper procedure uses your
steps (1) through (4), and then goes on with

(5) Alter the _copy_.
(6) Move the copy to your program source directory.
(7) In your program, replace <stdlib.hwith "name of the copy".

That way, other programs won't get hit by your changes when you forget
to change them back.

Richard

[Richard Bos]

Frederick Gotham <fg*******@SPAM.comwrote:

Keith Thompson:

Be sure to #undef malloc and free first; they can both be defined as
macros in <stdlib.h>.

Just out of curiosity, is that necessary? I know it would be the prefereable
thing to do (if only to suppress compiler warnings), but is it necessitated
by the Standard? The following source file only gives me a warning with gcc:

#define A 5
#define A 6

The Standard doesn't make any comment on the relative value of "warning"
and "error" messages. The only thing that _must_ prevent successful
compilation is an #error directive; for any other error, the Standard at
most requires a diagnostic. That diagnostic may or may not stop
compilation, as the compiler chooses.
In this case, the above code violates a constraint in [6.10.3#2] (a
macro may only be redefined without an intervening #undef if both
definitions are perfectly identical, except that whitespace must be
present in the same places in both definitions but may be different
whitespace, which 5 and 6 clearly are not), so a diagnostic must be
produced. That's all.

Richard

[Clever Monkey]

Frederick Gotham wrote:

In response to those who have replied regarding modification of <stdlib.h>:

I thought the OP had the source code for a program which had a memory
leak, and I thought he wanted to find the memory leak. I thought code which
hijacked "malloc" and "free" might help him find the memory leak. I didn't
mean for the code to be used indefinitely, but rather a "once off" sort of
thing.

This could be a fair assessment, I guess. The problem with handy tweaks
like this is that they assume a sort of naive understanding of the
implementation. I've certainly tweaked system headers in the past (on
early Linux, for example) to test something and then tweaked them right
back.

The problem is that one may introduce related issues that stem from the
system hack that may cause further confusion. I prefer treating the
implementation as a bit of a black box just for this reason.

I have to admit though that I haven't got much experience in the whole
"memory leak" game, as I read back over my code, and a "malloc" without a
corresponding "free" would stick out like a sore thumb to me.

Once your code gets big enough, you can end up having chunks of memory
past around from module to module for the entire lifetime of the app
process. There are no sore thumbs sticking out in the thousand-or-so
lines of code you can keep in your head in cases like this, I find.

That is to say, even shit-hot coders can introduce memory leaks, or
write code where it is easy to introduce memory leaks with maintenance.
C coders just have to be extra careful with the godlike access they
have to memory resources.

It's pretty standard around here, then, to have utility libraries in
scope that do a lot of workhorse stuff. This may actually be the only
chunk of code that includes <stdlib.h>. One such common utility
function is usually a "my_malloc()" which is the only interface to
memory allocation stuff.

Even if, at first, my_malloc() is a simple transparent wrapper around
malloc() it is usually extended at some point to have a compile-time
switch that controls whether plain, default malloc() is used or some
alternative debugging malloc-like routine.

Even if my_malloc() simply counts references/dereferences as you pointed
out earlier, this can be a big help.

I'm actually ignorant of the many static and dynamic memory debug tools
out there, which is why I'm most familiar with this old-skool method of
memory debugging.

[Giorgos Keramidas]

On Sun, 05 Nov 2006 16:07:38 GMT, Frederick Gotham <fg*******@SPAM.comwrote:

>Richard Heathfield:

>>Changing your implementation's [system headers] could be very
dangerous; don't consider doing it unless you know *exactly* what
you're doing.

If he knew exactly what he were doing, he would not be suggesting
changing system headers (least of all for something as trivial as
memory tracking).

If you had a few dozen source files which made use of "malloc" and
"free", then it would be a lot handier to play around with <stdlib.h>
than to go through each of them and add an inclusion directive.

It's quite trivial on my own computer:

(1) Find the directory where the compiler is installed.
(2) Look for a directory entitled something like "include".
(3) Look for "stdlib.h".
(4) Make a copy of it.
(5) Alter the original.

Which will have effect for all programs you are going to build with that
modified header after this point, but will have _NO_ effect whatsoever
on already compiled, object code.

Hijacking malloc() may sound like a good idea, at first, but it should
*never* be done as light-heartedly as you seem to imply in this thread.