What is memory leakage

Discussion in 'C Programming' started by Ramasubbu Ramasubramanian XR (AS/EAB), Mar 23, 2005.

  1. What is memory leakage, could any one explain with sample code
     
    Ramasubbu Ramasubramanian XR (AS/EAB), Mar 23, 2005
    #1
    1. Advertising

  2. Ramasubbu Ramasubramanian XR (AS/EAB)

    Mark Odell Guest

    Ramasubbu Ramasubramanian XR (AS/EAB) wrote:
    > What is memory leakage, could any one explain with sample code


    When your program slowly consumes system memory.

    int main(void)
    {
    char *pMembloc;

    // Never free().
    for (;;)
    {
    pMemblock = malloc(1024);
    }

    return 0;
    }
     
    Mark Odell, Mar 23, 2005
    #2
    1. Advertising

  3. Ramasubbu Ramasubramanian XR (AS/EAB)

    Guest

    On Wed, 23 Mar 2005 14:34:05 +0100, "Ramasubbu Ramasubramanian XR (AS/EAB)"
    <> wrote:

    >What is memory leakage, could any one explain with sample code

    void *X;
    X = malloc(32768); // ok so far
    X = malloc(16384); // you just orphaned the first block
    free(X); // first block is now leaked.

    When memory is allocated and not freed... they call it a "memory leak". Do
    it often enough and eventually you end up with no free memory.
     
    , Mar 23, 2005
    #3
  4. Mark Odell wrote:
    > Ramasubbu Ramasubramanian XR (AS/EAB) wrote:
    >
    >> What is memory leakage, could any one explain with sample code

    >
    >
    > When your program slowly consumes system memory.
    >
    > int main(void)
    > {
    > char *pMembloc;
    >
    > // Never free().
    > for (;;)
    > {
    > pMemblock = malloc(1024);
    > }
    >
    > return 0;
    > }
    >



    Slightly off-topic, when a program terminates, all the memory it had
    allocated is returned to the system, right? (Yeah, I know, system
    specific...) Or are there many systems that don't do that?
     
    =?ISO-8859-1?Q?Jos=E9_de_Paula?=, Mar 23, 2005
    #4
  5. Ramasubbu Ramasubramanian XR (AS/EAB) wrote:

    > What is memory leakage, could any one explain with sample code


    Ask Bill Gates. I hadn't heard of the term until about 8 years ago.
    http://msdn.microsoft.com/library/d...core98/html/_core_detecting_a_memory_leak.asp

    At the application level, failing to free RAM allocated by malloc, or not going garbage collection, is one thing.
    Bill Gates brought this to a new level by including memory allocation errors in the OS itself and in programming tools.

    gtoomey
     
    Gregory Toomey, Mar 23, 2005
    #5
  6. On Wed, 23 Mar 2005 11:56:02 -0300, José de Paula
    <> wrote:

    > Slightly off-topic, when a program terminates, all the memory it had
    > allocated is returned to the system, right? (Yeah, I know, system
    > specific...) Or are there many systems that don't do that?


    It's implementation defined. In practice, most hosted implementations
    will do that because there are thousands (or more) of programs which
    just exit and assume that the OS will clean up after them. However, at
    least one MSDOS compiler at one time used two mechanisms for memory
    allocation, small areas were allocated on the fixed space 'heap' and
    large ones used a direct OS call, the latter weren't always cleanly
    released. This was, however, pre-ANSI C (but I can't see anything in
    the C99 standard which states that memory is or is not automatically
    freed on program termination).

    Chris C
     
    Chris Croughton, Mar 23, 2005
    #6
  7. Ramasubbu Ramasubramanian XR (AS/EAB)

    Tor Rustad Guest

    "Ben Pfaff" <> wrote in message
    > Josi de Paula <> writes:
    >
    > > Slightly off-topic, when a program terminates, all the memory it had
    > > allocated is returned to the system, right? (Yeah, I know, system
    > > specific...) Or are there many systems that don't do that?

    >
    > This is "normally" the case, but it is not guaranteed by the
    > standard.


    True, this is a QoI issue.

    A conservative assumption is that we can replace "normal"
    by "highly normal"? I guess Ben P. too remember, that Dan
    Pop once gave an example of such an OS. There was also
    another c.l.c. regular that didn't trust Windows NT, to do such
    a cleanup properly in all cases.

    --
    Tor <torust AT online DOT no>
     
    Tor Rustad, Mar 23, 2005
    #7
  8. Ramasubbu Ramasubramanian XR (AS/EAB)

    Nils Weller Guest

    In article <Zlh0e.3210$>, Tor Rustad wrote:
    > "Ben Pfaff" <> wrote in message
    >> Josi de Paula <> writes:
    >>
    >> > Slightly off-topic, when a program terminates, all the memory it had
    >> > allocated is returned to the system, right? (Yeah, I know, system
    >> > specific...) Or are there many systems that don't do that?

    >>
    >> This is "normally" the case, but it is not guaranteed by the
    >> standard.

    >
    > True, this is a QoI issue.
    >
    > A conservative assumption is that we can replace "normal"
    > by "highly normal"?


    Some people keep saying that not free()'ing everything before program
    termination is potentially dangerous, but I have never seen anyone
    provide a *concrete* example of an implementation that actually requires
    this to avoid memory leaks.

    It appears that there are no such implementations, and even if you could
    come up with one or two exotic, historical and barely used examples,
    then they were highly unlikely to be a viable target for software
    development in C today. And even if they do exist and are a viable
    target to some, then the fact that the implementation cannot even clean
    up all memory implies that it is a highly specialized and limited
    platform where free() vs. no free() is just one among many other
    problems that need to be addressed (or in other words: if you're writing
    for such a system, then free() is the least of your worries, and
    religiously calling free() all the time will not magically make your
    code work well on it.)

    The fact is that neither the C standard, nor the known C implementations
    (unless someone can finally provide a counter example), provide any
    basis for having to call free() before program termination.

    > I guess Ben P. too remember, that Dan
    > Pop once gave an example of such an OS. There was also
    > another c.l.c. regular that didn't trust Windows NT, to do such
    > a cleanup properly in all cases.


    I can't recall seeing Dan Pop mention an example implementation, but I
    do recall him giving another good reason as to why the free() argument
    is bogus: If the system cannot clean up the heap, what will happen to
    all other memory of your program - the memory whose deallocation is even
    more (and I say ``more'' because most common free() implementations do
    not actually return anything to the operating system; In most cases they
    just save it for subsequent malloc() requests, and the hardware page
    size makes this technically impossible for small memory chunks anyway)
    outside of your control, typically stack, code and data segments?

    --
    My real email address is ``nils<at>gnulinux<dot>nl''
     
    Nils Weller, Mar 23, 2005
    #8
  9. Ramasubbu Ramasubramanian XR (AS/EAB)

    Tor Rustad Guest

    "Nils Weller" <> wrote in message
    > In article <Zlh0e.3210$>, Tor Rustad wrote:
    > > "Ben Pfaff" <> wrote in message
    > >>
    > >> This is "normally" the case, but it is not guaranteed by the
    > >> standard.

    > >
    > > True, this is a QoI issue.
    > >
    > > A conservative assumption is that we can replace "normal"
    > > by "highly normal"?

    >
    > Some people keep saying that not free()'ing everything before program
    > termination is potentially dangerous, but I have never seen anyone
    > provide a *concrete* example of an implementation that actually
    > requires this to avoid memory leaks.


    As I said, Dan Pop gave _one_ such an example, I would put it
    in the exotic & historical category, can't even remember what it
    was called anymore. :)

    The NT case, was never proven/demonstrated...


    > It appears that there are no such implementations, and even if you
    > could
    > come up with one or two exotic, historical and barely used examples,
    > then they were highly unlikely to be a viable target for software
    > development in C today. And even if they do exist and are a viable
    > target to some, then the fact that the implementation cannot even
    > clean
    > up all memory implies that it is a highly specialized and limited
    > platform where free() vs. no free() is just one among many other
    > problems that need to be addressed (or in other words: if you're
    > writing
    > for such a system, then free() is the least of your worries, and
    > religiously calling free() all the time will not magically make your
    > code work well on it.)
    >
    > The fact is that neither the C standard, nor the known C
    > implementations
    > (unless someone can finally provide a counter example), provide any
    > basis for having to call free() before program termination.


    I more or less agree with this. However, if writing a non-stop server,
    I care a lot about *not* leaking any memory. OTOH, short-lived
    programs running on a stable kernel with VM support, I don't see the
    problem with "memory leaking" at all.


    > I can't recall seeing Dan Pop mention an example implementation, but I
    > do recall him giving another good reason as to why the free() argument
    > is bogus: If the system cannot clean up the heap, what will happen to
    > all other memory of your program - the memory whose deallocation is
    > even
    > more (and I say ``more'' because most common free() implementations do
    > not actually return anything to the operating system; In most cases
    > they
    > just save it for subsequent malloc() requests, and the hardware page
    > size makes this technically impossible for small memory chunks anyway)
    > outside of your control, typically stack, code and data segments?


    Good point.

    --
    Tor <torust AT online DOT no>
     
    Tor Rustad, Mar 23, 2005
    #9
  10. Ramasubbu Ramasubramanian XR (AS/EAB)

    Nils Weller Guest

    In article <ZIi0e.3228$>, Tor Rustad wrote:
    > "Nils Weller" <> wrote in message
    >> In article <Zlh0e.3210$>, Tor Rustad wrote:
    >> > "Ben Pfaff" <> wrote in message

    >> [...]
    >> Some people keep saying that not free()'ing everything before program
    >> termination is potentially dangerous, but I have never seen anyone
    >> provide a *concrete* example of an implementation that actually
    >> requires this to avoid memory leaks.

    >
    > As I said, Dan Pop gave _one_ such an example, I would put it
    > in the exotic & historical category, can't even remember what it
    > was called anymore. :)


    I recall that Dan Pop mentioned an example of a system where the
    operating system is not capable of freeing the memory, but on that
    implementation (Amiga, IIRC), the C runtime takes care of the issue, so
    it is NOT an example of an implementation where you have to call free()
    in order to prevent memory leakage. Or are you thinking of another
    example? If so, please provide concrete references.

    >> The fact is that neither the C standard, nor the known C
    >> implementations
    >> (unless someone can finally provide a counter example), provide any
    >> basis for having to call free() before program termination.

    >
    > I more or less agree with this. However, if writing a non-stop server,
    > I care a lot about *not* leaking any memory. OTOH, short-lived
    > programs running on a stable kernel with VM support, I don't see the
    > problem with "memory leaking" at all.


    Nobody argued that memory leaks inside of your application are okay; We
    are discussing whether or not not free()'ing all dynamically allocated
    memory before program termination actually causes a leak that
    subsequently affects the system and other applications running on it.

    --
    My real email address is ``nils<at>gnulinux<dot>nl''
     
    Nils Weller, Mar 23, 2005
    #10
  11. Ramasubbu Ramasubramanian XR (AS/EAB)

    Tor Rustad Guest

    "Nils Weller" <> wrote in message
    news:...
    > In article <ZIi0e.3228$>, Tor Rustad wrote:
    > > "Nils Weller" <> wrote in message
    > >> In article <Zlh0e.3210$>, Tor Rustad wrote:


    [...]

    > > As I said, Dan Pop gave _one_ such an example, I would put it
    > > in the exotic & historical category, can't even remember what it
    > > was called anymore. :)

    >
    > I recall that Dan Pop mentioned an example of a system where the
    > operating system is not capable of freeing the memory, but on that
    > implementation (Amiga, IIRC), the C runtime takes care of the issue,
    > so it is NOT an example of an implementation where you have to
    > call free() in order to prevent memory leakage.


    Ahh.. yes Amiga DOS was the one! You are right, there was cleanup
    code in the runtime library...

    Dan's chief point, was that if a system isn't able to reclaim unfree'ed
    memory on program termination, then the same would be likely for
    the free'ed memory.

    --
    Tor <torust AT online DOT no>
     
    Tor Rustad, Mar 23, 2005
    #11
  12. Ramasubbu Ramasubramanian XR (AS/EAB) wrote on 23/03/05 :
    > What is memory leakage, could any one explain with sample code


    When you allocate some memory block and never free it. On 24h per day
    running machines, such a behaviour is lethal.

    --
    Emmanuel
    The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
    The C-library: http://www.dinkumware.com/refxc.html

    "Mal nommer les choses c'est ajouter du malheur au
    monde." -- Albert Camus.
     
    Emmanuel Delahaye, Mar 23, 2005
    #12
  13. José de Paula wrote on 23/03/05 :
    > Slightly off-topic, when a program terminates, all the memory it had
    > allocated is returned to the system, right? (Yeah, I know, system
    > specific...) Or are there many systems that don't do that?


    Daemons don't terminate... They eat memory...

    --
    Emmanuel
    The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
    The C-library: http://www.dinkumware.com/refxc.html

    "There are 10 types of people in the world today;
    those that understand binary, and those that dont."
     
    Emmanuel Delahaye, Mar 23, 2005
    #13
  14. Ramasubbu Ramasubramanian XR (AS/EAB)

    CBFalconer Guest

    Tor Rustad wrote:
    > "Ben Pfaff" <> wrote in message
    >> Josi de Paula <> writes:
    >>
    >>> Slightly off-topic, when a program terminates, all the memory it
    >>> had allocated is returned to the system, right? (Yeah, I know,
    >>> system specific...) Or are there many systems that don't do that?

    >>
    >> This is "normally" the case, but it is not guaranteed by the
    >> standard.

    >
    > True, this is a QoI issue.
    >
    > A conservative assumption is that we can replace "normal"
    > by "highly normal"? I guess Ben P. too remember, that Dan
    > Pop once gave an example of such an OS. There was also
    > another c.l.c. regular that didn't trust Windows NT, to do such
    > a cleanup properly in all cases.


    OTOH there are cases when you want to let the OS do the cleanup.
    Most malloc systems out there have an O(n) free algorithm, where n
    is the number of blocks, allocated or freed, in existence. The n
    arises from the efforts to join adjacent freed blocks. This means
    that the programs final effort to free the large n blocks it has is
    O(n*n), and can be very annoying.

    Some of the test cases for hashlib can easily trigger this
    behavior. Those cases have the option of just not doing the final
    free sequence. I found the bad behaviour on every system I tested.

    I ran into this very annoying behaviour during testing of hashlib,
    and the result was the writing of nmalloc, to eliminate the O(n)
    free [now O(1)]. Both are available at:

    <http://cbfalconer.home.att.net/download/>

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Mar 23, 2005
    #14
  15. Ben Pfaff <> writes:
    > Josi de Paula <> writes:
    >
    >> Slightly off-topic, when a program terminates, all the memory it had
    >> allocated is returned to the system, right? (Yeah, I know, system
    >> specific...) Or are there many systems that don't do that?

    >
    > This is "normally" the case, but it is not guaranteed by the
    > standard.


    The standard doesn't guarantee that un-free()d memory is reclaimed
    when the program terminates.

    The standard also doesn't guarantee that free()d memory is reclaimed
    when the program terminates.

    Calling free() causes a memory block to become available for further
    allocation within the program; it doesn't necessarily return it to the
    operating system (and it typically doesn't). The standard doesn't say
    what happens when the program terminates.

    (Having said that, an OS that doesn't reclaim even free()d memory on
    program termination would be painful.)

    --
    Keith Thompson (The_Other_Keith) <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.
     
    Keith Thompson, Mar 24, 2005
    #15
  16. Ramasubbu Ramasubramanian XR (AS/EAB)

    Jack Klein Guest

    On Wed, 23 Mar 2005 11:56:02 -0300, José de Paula
    <> wrote in comp.lang.c:

    > Mark Odell wrote:
    > > Ramasubbu Ramasubramanian XR (AS/EAB) wrote:
    > >
    > >> What is memory leakage, could any one explain with sample code

    > >
    > >
    > > When your program slowly consumes system memory.
    > >
    > > int main(void)
    > > {
    > > char *pMembloc;
    > >
    > > // Never free().
    > > for (;;)
    > > {
    > > pMemblock = malloc(1024);
    > > }
    > >
    > > return 0;
    > > }
    > >

    >
    >
    > Slightly off-topic, when a program terminates, all the memory it had
    > allocated is returned to the system, right? (Yeah, I know, system
    > specific...) Or are there many systems that don't do that?


    That depends on the system, something over which the C language
    standard has no control. It is a QOI issue with the platform.

    Even assuming that a compiler's C run time library walked its active
    allocation list and free'd everything after main() returned or exit()
    was called, sometimes programs crash, preventing any clean up in the
    run time library from executing.

    As for those who ask for concrete examples, there were early versions
    of MS-DOS, 2.x for sure and I think 3.x, the could lose it if a
    program terminated without deallocating memory it allocated while
    running. You would end up with a prompt on the screen something like
    "Can't load command.com, system halted".

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Mar 24, 2005
    #16
  17. On Wed, 23 Mar 2005 21:58:44 +0100, Emmanuel Delahaye wrote:

    > Ramasubbu Ramasubramanian XR (AS/EAB) wrote on 23/03/05 :
    >> What is memory leakage, could any one explain with sample code

    >
    > When you allocate some memory block and never free it.


    That's not quite right. A memory leak is where a memory block hasn't been
    freed, but the program loses all means to reference it. A related but
    subtly different situation is where a program doesn't free a memory block
    it no longer needs, but still maintains the ability to reference it. E.g.
    garbage collection systems can help with the former but not the latter.

    It is quite possible for a correct program to allocate memory and never
    free it, indeed it is common. For example the program can maintain
    data that is relevant right up until the program terminates. The downside
    here is debugging, some debugging environments can report unfreed memory
    allocations on program termination as potential memory leaks. The utility
    of this is greatly reduced if the program doesn't clear up allocated
    memory.

    There have been discussions as to whether C requires memory to be "freed"
    on program termination. It doesn't, but that's the wrong question -
    dynamic memory allocation space (sometimes referred to as a "heap") only
    exists in the context of the program's execution environment, i.e. when
    the program terminates the "heap" no longer exists. The more useful
    question is whether when the program terminates memory allocated by the
    program is reclaimed by whatever OS/environment caused the program to be
    run in the first place. This is outside the scope of the
    execution/behaviour of the C program so the standard says nothing about it.

    It has been argued that since C doesn't require unfreed memory to be
    reclaimed on program termination, that is a reason to make sure
    that all allocated memory is freed. However C doesn't require that any
    resources used by the C program be reclaimed (except that files be closed
    on normal termination); static, automatic variables, program code and even
    freed memory need not be reclaimed either. So this is not itself a reason
    to free memory. It is possible that real-world implementations don't
    reclaim unfreed memory but that's rare to non-existant these days.

    > On 24h per day
    > running machines, such a behaviour is lethal.


    The problem tends to be when a program does either of the above
    repeatedly, i.e. keeps more and more memory allocated that it no longer
    uses.

    Lawrence
     
    Lawrence Kirby, Mar 24, 2005
    #17
  18. Ramasubbu Ramasubramanian XR (AS/EAB)

    Tor Rustad Guest

    "Jack Klein" <> wrote in message

    <snip>

    > Even assuming that a compiler's C run time library walked its active
    > allocation list and free'd everything after main() returned or exit()
    > was called, sometimes programs crash, preventing any clean up in the
    > run time library from executing.


    Yes. To have a stable OS, the kernel need to run in a protected
    memory space and to control memory cleanups after programs
    terminating in user space.

    Even if the runtime library register a __freeall() function, which is
    called in case of interrupts/exceptions, the runtime library can't
    protect against wild pointers corrupting the heap arena (unless
    using protected memory space).


    > As for those who ask for concrete examples, there were early versions
    > of MS-DOS, 2.x for sure and I think 3.x, the could lose it if a
    > program terminated without deallocating memory it allocated while
    > running. You would end up with a prompt on the screen something like
    > "Can't load command.com, system halted".


    Did DOS run x86 in protected mode before Windows came along?
    I can't recall that I had problems reading/writing to any memory
    address under DOS. C programming & DOS was... "fun". :)

    However, even in case of a program crash, it isn't obvious that
    explicit free() calls, would change anything w.r.t. memory leaks.

    --
    Tor <torust AT online DOT no>
     
    Tor Rustad, Mar 29, 2005
    #18
  19. Ramasubbu Ramasubramanian XR (AS/EAB)

    Tor Rustad Guest

    "Lawrence Kirby" <> wrote in message

    <snip>

    > It has been argued that since C doesn't require unfreed memory to be
    > reclaimed on program termination, that is a reason to make sure
    > that all allocated memory is freed. However C doesn't require that any
    > resources used by the C program be reclaimed (except that files be
    > closed
    > on normal termination); static, automatic variables, program code and
    > even
    > freed memory need not be reclaimed either. So this is not itself a
    > reason
    > to free memory. It is possible that real-world implementations don't
    > reclaim unfreed memory but that's rare to non-existant these days.


    Agreed. It should however be pointed out that we here talk about
    programs that run in "user space". Let say our program is part of
    a kernel or is a device driver, then such code must take great
    care in manually free'ing allocated memory.

    For example on Linux, kmalloc()/kfree() and vmalloc()/vmfree() take
    the role of malloc()/free().

    --
    Tor <torust AT online DOT no>
     
    Tor Rustad, Mar 29, 2005
    #19
    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. Gaël

    w3wp crash and memory leakage

    Gaël, Oct 15, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    2,716
    Alvin Bruney
    Oct 16, 2003
  2. John Hilton

    How to identify the memory leakage...

    John Hilton, Dec 16, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    327
    John Hilton
    Dec 16, 2004
  3. Sambucus
    Replies:
    19
    Views:
    901
    George Neuner
    May 6, 2004
  4. Devian
    Replies:
    7
    Views:
    391
    Babu Kalakrishnan
    Sep 20, 2004
  5. E. Naubauer
    Replies:
    6
    Views:
    3,038
    Roedy Green
    Feb 24, 2006
Loading...

Share This Page