Memory Leak Programs

C

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
 
F

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

Walter Roberson

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

c language

Frederick said:
c language:



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
 
B

Bill Pursell

c said:
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.
 
F

Frederick Gotham

c language:
I don't know how to do this

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.h> file 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;
}
 
K

Keith Thompson

Frederick Gotham said:
c language:
I don't know how to do this

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.h> file and change it.

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

EKB

c said:
I don't know how to do this


I don't know how to do this

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
 
R

Richard Heathfield

Keith Thompson said:

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

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
 
F

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

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

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.h> than 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.
 
F

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

Richard Heathfield

Frederick Gotham said:
Richard Heathfield:


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

Gordon Burditt

Changing your implementation's [system headers] could be very dangerous;
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.

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

Keith Thompson

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.h> than 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.
 
I

Ian Collins

Frederick said:
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 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>
 
M

Mark McIntyre

Richard Heathfield:


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
 
M

Mark McIntyre

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.

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
 
F

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,776
Messages
2,569,603
Members
45,185
Latest member
GluceaReviews

Latest Threads

Top