Memory Leak Programs

[Ian Collins]

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!

 

[Richard Bos]

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.

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.h> with "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]

Keith Thompson:


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]

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]

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.