purge like utility in c

Discussion in 'C Programming' started by ramasubramanian.rahul@gmail.com, Oct 10, 2006.

  1. Guest

    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
     
    , Oct 10, 2006
    #1
    1. Advertising

  2. wrote:
    > 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, Oct 10, 2006
    #2
    1. Advertising

  3. 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.
     
    Ancient_Hacker, Oct 10, 2006
    #3
  4. Chris Dollin Guest

    Ancient_Hacker wrote:

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

    --
    Chris "Essen -9 and counting" Dollin
    The shortcuts are all full of people using them.
     
    Chris Dollin, Oct 10, 2006
    #4
  5. Eric Sosman Guest

    Ancient_Hacker wrote:

    > wrote:
    >
    >>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().


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

    --
    Eric Sosman
    lid
     
    Eric Sosman, Oct 10, 2006
    #5
  6. On Tue, 10 Oct 2006 08:00:44 -0400, Eric Sosman wrote:
    > 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
     
    Roland Pibinger, Oct 10, 2006
    #6
  7. In article <>,
    Roland Pibinger <> wrote:
    >BTW, the Standard C library
    >doesn't allocate objects that have to be freed by the caller.


    malloc() does...

    -- Richard
     
    Richard Tobin, Oct 10, 2006
    #7
  8. Chris Dollin Guest

    Roland Pibinger wrote:

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

    --
    Chris "Essen -9 and counting" Dollin
    The shortcuts are all full of people using them.
     
    Chris Dollin, Oct 10, 2006
    #8
  9. jacob navia Guest

    wrote:
    > 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
     
    jacob navia, Oct 10, 2006
    #9
  10. Chris Dollin Guest

    jacob navia wrote:

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


    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.

    --
    Chris "Essen -9 and counting" Dollin
    "No-one here is exactly what he appears." G'kar, /Babylon 5/
     
    Chris Dollin, Oct 10, 2006
    #10
  11. jacob navia said:

    <snip>

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

    --
    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)
     
    Richard Heathfield, Oct 10, 2006
    #11
  12. jacob navia Guest

    Chris Dollin wrote:
    > jacob navia wrote:
    >
    >
    >> wrote:
    >>
    >>>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.

    >
    >
    > 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
     
    jacob navia, Oct 10, 2006
    #12
  13. 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...

    --
    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)
     
    Richard Heathfield, Oct 10, 2006
    #13
  14. jacob navia Guest

    Richard Heathfield wrote:
    > jacob navia said:
    >
    > <snip>
    >
    >>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.
    >


    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, Oct 10, 2006
    #14
  15. jacob navia Guest

    Richard Heathfield wrote:
    > 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...
    >


    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
     
    jacob navia, Oct 10, 2006
    #15
  16. Richard Bos Guest

    jacob navia <> wrote:

    > Richard Heathfield wrote:
    > > 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.

    >
    > 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
     
    Richard Bos, Oct 10, 2006
    #16
  17. jacob navia Guest

    Richard Bos wrote:
    > jacob navia <> wrote:
    >
    >
    >>Richard Heathfield wrote:
    >>
    >>>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.

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


    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
     
    jacob navia, Oct 10, 2006
    #17
  18. James Antill Guest

    On Tue, 10 Oct 2006 14:19:12 +0000, Roland Pibinger wrote:

    > On Tue, 10 Oct 2006 08:00:44 -0400, Eric Sosman wrote:
    >>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.


    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.

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


    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.

    --
    James Antill --
    http://www.and.org/and-httpd
     
    James Antill, Oct 10, 2006
    #18
  19. On Tue, 10 Oct 2006 15:32:40 +0100, Chris Dollin wrote:
    >Roland Pibinger wrote:
    >> 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.


    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
     
    Roland Pibinger, Oct 10, 2006
    #19
  20. jacob navia said:

    <snip>

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

    --
    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)
     
    Richard Heathfield, Oct 10, 2006
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?RGF2aWQ=?=

    Diable Explorer Button or Purge History List

    =?Utf-8?B?RGF2aWQ=?=, Feb 19, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    384
    =?Utf-8?B?RGF2aWQ=?=
    Feb 19, 2004
  2. Signal

    File Read Cache - How to purge?

    Signal, Aug 21, 2007, in forum: Python
    Replies:
    14
    Views:
    506
    Hrvoje Niksic
    Aug 22, 2007
  3. how to purge backup files

    , May 10, 2005, in forum: Perl Misc
    Replies:
    4
    Views:
    193
    Joe Smith
    May 11, 2005
  4. afrinspray
    Replies:
    0
    Views:
    117
    afrinspray
    May 9, 2006
  5. afrinspray

    MIME::Parser and Purge / Prune

    afrinspray, May 31, 2006, in forum: Perl Misc
    Replies:
    1
    Views:
    124
    afrinspray
    Jun 9, 2006
Loading...

Share This Page