purge like utility in c

[ramasubramanian.rahul]

hi .. can we design a program in c which will point out the possible
memory leaks in any given c file and fix them.... i am trying to come
with something like this but do not know where to start...

any help on where to begin would be highly appriciated
kind regards
rahul

 

[Ancient_Hacker]

hi .. can we design a program in c which will point out the possible
memory leaks in any given c file and fix them.... i am trying to come
with something like this but do not know where to start...

any help on where to begin would be highly appriciated
kind regards
rahul

well, any use of malloc() without a later free() is going to leak....
But I think it's ttheoretically impossible to figure out what mallocs()
never do a free() without executing all possible paths thru the code
with all possible inputs.

The best way is to write really structured code, something like this:

p = malloc( ... );
dosomethingwith(p);
free( p );

.... and don't have any other paths that can bypass the free().


In practice what's usually done is you write really crappy spaghetti
code, with the free()'s nowhere near the malloc()'s, then use a logging
malloc(), such as www.dmalloc.com gives out, then you run your program,
with luck having it exercise all the possible code paths, then you look
at the list of still-allocated blocks.

The last time I did so, I forgot to free one important struct of
pointers so there were something like 36,337 unfreed pointers using
124,543,000 bytes. Ouch. You should really just write good code in
the first place.

 

[Ancient_Hacker]

Another way to make your code even safer is to have a strait-jacket
macro or function wrapper which makes it darn near impossible to not
free things, something like:

#define Serious_Wrapper(var,type,size,proc) \
{ type var; var = malloc( size ); proc( var ); free( var ); }


.... but of course this often doesnt fit in well with the flow of your
code. Sigh.

 

[Chris Dollin]

Another way to make your code even safer is to have a strait-jacket
macro or function wrapper which makes it darn near impossible to not
free things, something like:

#define Serious_Wrapper(var,type,size,proc) \
{ type var; var = malloc( size ); proc( var ); free( var ); }


... but of course this often doesnt fit in well with the flow of your
code. Sigh.

Oh happy days of BCPL's aptovec.

 

[Eric Sosman]

well, any use of malloc() without a later free() is going to leak....
But I think it's ttheoretically impossible to figure out what mallocs()
never do a free() without executing all possible paths thru the code
with all possible inputs.

The best way is to write really structured code, something like this:

p = malloc( ... );
dosomethingwith(p);
free( p );

... and don't have any other paths that can bypass the free().

A drawback of this advice is that it ties the lifetime of
the dynamic variable to a lexical scope of the code. That is,
it removes most of the reason for having dynamic storage in
the first place; the only advantage over plain `auto' variables
would be the (possibly) less stringent size restrictions.

The chief reason for using dynamic memory is to create
objects whose lifetime is independent of the execution context.
I want to be able to malloc() something in a function, add the
something to a hash table or splay tree or some such, and return
from the function with the something still intact. If I'm not
allowed to do that, there's little point in having malloc().

 

[Roland Pibinger]

A drawback of this advice is that it ties the lifetime of
the dynamic variable to a lexical scope of the code.

That's a feature not a drawback!

That is,
it removes most of the reason for having dynamic storage in
the first place; the only advantage over plain `auto' variables
would be the (possibly) less stringent size restrictions.

.... which really is a huge advantage. Symmetric resource acquisition
and release is the most powerful resource management pattern in C.

The chief reason for using dynamic memory is to create
objects whose lifetime is independent of the execution context.

That's no contradiction to symmetric resource management.

I want to be able to malloc() something in a function, add the
something to a hash table or splay tree or some such, and return
from the function with the something still intact. If I'm not
allowed to do that, there's little point in having malloc().

If you feel the need to return a dynamically allocated object just
allocate it one scope higher and pass it to the function thereby
preserving symmetry of de-/allocation. BTW, the Standard C library
doesn't allocate objects that have to be freed by the caller.

Best regards,
Roland Pibinger

 

[Richard Tobin]

BTW, the Standard C library
doesn't allocate objects that have to be freed by the caller.

malloc() does...

-- Richard

 

[Chris Dollin]

If you feel the need to return a dynamically allocated object just
allocate it one scope higher and pass it to the function thereby
preserving symmetry of de-/allocation.

Not obviously possible in general. For example, a parser that delivers
an abstract syntax tree: you don't know what to allocate until you
come to allocate it.

(Also, detaching allocation from initialisation is an open invitation
to misuse the consequent mutability of the tree objects.)

 

[jacob navia]

hi .. can we design a program in c which will point out the possible
memory leaks in any given c file and fix them.... i am trying to come
with something like this but do not know where to start...

any help on where to begin would be highly appriciated
kind regards
rahul

Stop messing with malloc/free and use a garbage collector.
The machine will do the hard work, you do the driving.

jacob

 

[Chris Dollin]

Stop messing with malloc/free and use a garbage collector.
The machine will do the hard work, you do the driving.

Be aware that if you do so you are leaving Standard C. That
may be a reasonable choice for generic-you, or it may not.
Make sure generic-you understand the consequences.

If one is prepared to give up C standardness for garbage collection,
there are other languages Out There that come with GC as standard.
Some of them are even designed for it.

 

[Richard Heathfield]

jacob navia said:

Stop messing with malloc/free and use a garbage collector.

C doesn't have one, as you either know or ought to know. Stop trolling.

 

[jacob navia]

jacob navia wrote:




Be aware that if you do so you are leaving Standard C. That
may be a reasonable choice for generic-you, or it may not.
Make sure generic-you understand the consequences.

If one is prepared to give up C standardness for garbage collection,
there are other languages Out There that come with GC as standard.
Some of them are even designed for it.

C was designed with a GC in mind.

That is why the provided standard functions are so error-prone
and full of hazards for the unwary. Because you are supposed to
use the GC obviously!



Besides, all other languages do not provide with the efficiency
of C. Coupled with a good GC, the need for destructors, and
all the associated machinery disappears. You obtain a simpler,
easier to use language, without the problems of other "OO"
stuff.

jacob

 

[Richard Heathfield]

(e-mail address removed) said:

hi .. can we design a program in c which will point out the possible
memory leaks in any given c file and fix them....

It is not possible to write a program that will point out all possible leaks
in any arbitrary program, with no false positives; to do so would be
equivalent to solving the Halting Problem.

It is, however, trivial to set up a system which detects and reports actual
leaks. I wrote one myself, for my own use, so it can't be that hard, can
it? But of course there is always valgrind...

 

[jacob navia]

jacob navia said:




C doesn't have one, as you either know or ought to know. Stop trolling.

What "C"?

Yours?

The garbage collector can be used as an external library.
If you do not recommend its use, or somehow are GC impaired
that is YOUR opinion.

Mine is that many people are wasting a lot of time
chasing bugs related to malloc/free instead of programming
their application.


They should use a GC and be done with it.

jacob

 

[jacob navia]

(e-mail address removed) said:




It is not possible to write a program that will point out all possible leaks
in any arbitrary program, with no false positives; to do so would be
equivalent to solving the Halting Problem.

It is, however, trivial to set up a system which detects and reports actual
leaks. I wrote one myself, for my own use, so it can't be that hard, can
it? But of course there is always valgrind...

Interesting. You recommend valgrind, but you are against a Garbage
Collector.

Does "C" has a "valgrind"????

No, I do not find that word in my copy of the C standard. But that is OK
of course. You can recommend valgrind, but when I recommend a garbage
collector the hell rains over me and I am flamed of being "a troll".

Gosh Heathfield, just stop that ok?

You ARE entitled to your opinion and if you find valgrind OK it IS OK
to recommend it to anyone. But when I recommend a GC, please stop
treating me of "troll" or saying the "C doesn't have a GC".

OK?

Thanks

 

[Richard Bos]

What "C"?

Yours?

_The_ C. The one defined by the International Organisation for
Standards. Which, last time I looked, France was a signatory to, as
well.

They should use a GC and be done with it.

If "they" want pain, inefficiency, and leaky programs, yes.

Richard

 

[jacob navia]

_The_ C. The one defined by the International Organisation for
Standards. Which, last time I looked, France was a signatory to, as
well.




If "they" want pain, inefficiency, and leaky programs, yes.

Richard

Pain?

Look, seeing the pain in the... of malloc/free, the problems of a GC
are nothing at all.

Inefficiency? And when you malloc something you think that malloc
doesn't do a GC to compact memory? malloc is not free, it can be
vary expensive.

jacob

 

[James Antill]

... which really is a huge advantage. Symmetric resource acquisition
and release is the most powerful resource management pattern in C.

Define "most powerful". It's certainly not the most useful in many cases.
And for many "types" pre-allocating is very much not the safest option
(like string types). It also strongly ties the caller to the callee
implicitly, which you often don't want from a design/quality POV.

If you feel the need to return a dynamically allocated object just
allocate it one scope higher and pass it to the function thereby
preserving symmetry of de-/allocation.

Again, this implies that the callee knows what the caller is allocating
and still the lifetime may extend well beyond the call. For instance a
network connection to an event based daemon wouldn't want the event
handling code to know about the full objects being allocated, and it would
need to remain over CONNECT/READ/WRITE/SHUTDOWN events. Which could be
many trips through the main loop.

BTW, the Standard C library
doesn't allocate objects that have to be freed by the caller.

Well apart from *alloc, there are at least two in the Std. library: fopen
and tmpfile. Both due to not wanting the callee to have to know intimately
about the object created. If you then get out of the theoretical there
are many more examples like: asprintf, acl_get_file and opendir.

 

[Roland Pibinger]

Not obviously possible in general.

Not possible in general but in so many cases that I'd call it _the_ C
resource management idiom (pattern).

For example, a parser that delivers
an abstract syntax tree: you don't know what to allocate until you
come to allocate it.

That's not a contradiction to the quest for symmetry of allocation and
deallocation as long as the scope of both is the same.

Best wishes,
Roland Pibinger

 

[Richard Heathfield]

jacob navia said:

C was designed with a GC in mind.

Can you support this claim?

That is why the provided standard functions are so error-prone
and full of hazards for the unwary. Because you are supposed to
use the GC obviously!

No, programmers are supposed to be wary.