What does free return?

Discussion in 'C Programming' started by siliconwafer, Dec 14, 2005.

  1. siliconwafer

    siliconwafer Guest

    What does free return?i.e how can we be sure that free has freed the
    exact amount of memory we allocated?How can we be sure that there is no
    memory tagged in the machine when we quit the C application?
     
    siliconwafer, Dec 14, 2005
    #1
    1. Advertising

  2. siliconwafer

    bluejack Guest

    siliconwafer wrote...
    >What does free return?i.e how can we be sure that free has freed the
    >exact amount of memory we allocated?How can we be sure that there is no
    >memory tagged in the machine when we quit the C application?


    free does not return anything:

    #include <stdlib.h>
    void free(void *ptr);

    "void" means it doesn't return anything.

    Well, you could trust that any conforming implementation will be
    correct (which would be the best use of your time), or you could
    measure it to see if it frees exactly the number of bytes that malloc,
    calloc, or realloc actually allocate.

    Upon exiting an application, it is the kernel of your operating system
    that reclaims memory. If you never called free on a single chunk of
    dynamically allocated memory, and then exitted the application, all the
    memory allocated within the process would be returned to the kernel.
     
    bluejack, Dec 14, 2005
    #2
    1. Advertising

  3. siliconwafer

    Jordan Abel Guest

    On 2005-12-14, bluejack <> wrote:
    > Upon exiting an application, it is the kernel of your operating system
    > that reclaims memory. If you never called free on a single chunk of
    > dynamically allocated memory, and then exitted the application, all the
    > memory allocated within the process would be returned to the kernel.


    I have been told that this is implementation-defined, and that there may
    in principle be conforming implementations where the memory just sits
    there useless if not reclaimed before exit.
     
    Jordan Abel, Dec 14, 2005
    #3
  4. In article <>,
    siliconwafer <> wrote:
    >What does free return?


    Nothing. It has a void result, which means it returns no result, ever.

    >i.e how can we be sure that free has freed the
    >exact amount of memory we allocated?


    You cannot, and it many implementations it does not. In many
    implementations it returns -more- than the exact amount of
    memory you allocated.

    In many implementations a size_t before the space allocated is used to
    keep track of the size of the block (notice you don't specify how much
    memory to free, which implies something is keeping track of the size
    that was allocated.) size_t does not, however, generally meet the
    alignment requirements imposed on malloced memory (which has to return
    memory suitable for allocation to double or long double or long long),
    so it is not uncommon for there to be some bytes of unused padding
    before the block. When you free() the memory, not only the memory
    itself but these common (but not universal) overhead bytes get
    released for reuse -- so the released size often does not match
    the memory size explicitly allocated.

    Now, the implementation may promptly seize some of that released
    memory to keep track of the free space...


    >How can we be sure that there is no
    >memory tagged in the machine when we quit the C application?


    You are, at most, responsible for free()ing only what you allocated.
    Anything else is up to the implementation to deal with on its own.


    The question is really only relevant on a non-"hosted" implementation.
    Any "hosted" implementation is going to automatically recover all
    process memory, whether automatic or call stack or jump stack or
    file buffer or static or string literals or malloc() or
    calloc() or executable code or whatever. If it failed to do that,
    then when a program bombed (e.g., invoked one of the undefined
    or forbidden behaviours) the memory would be lost and over time
    all memory would get chewed up, requiring a reboot. So hosted
    implementations do all the cleanup work anyhow.

    Non-hosted implementations are less well defined -- what would
    it mean for your wristwatch to return all its allocated
    memory at the end of the program, considering that the program
    is never supposed to end?

    Usually, at the implementation level, it is trivial to deallocate
    all allocated memory -- just a matter of re-initializing a
    CPU register or two and scribbling a "all memory is available"
    message into the space the implementation uses to keep track of
    allocated memory.


    Probably all that should really be of concern to you is the
    matter of whether the implementation gives back the free()'d
    memory to the operating system. The answer to that is multifold:

    a) It usually doesn't, because memory is obtained from the
    operating system in "pages", and the operating system can only
    accept returning complete pages at the best of times -- so if you
    allocate 1000 bytes then 10 bytes then free the 1000 bytes,
    the implmentation probably could not turn that memory back over
    to the OS because the 10 byte chunk that is still in use is
    probably on the same system memory page.

    b) It would be possible to go through the non-trivial trouble of
    noticing that a complete system memory page has been reclaimed (after
    a series of malloc() and free() operations, but many operating
    are only able to accept returning of pages at the -end- of
    allocated memory, not in the middle of an address space, so
    it is common for implmentations to never give back memory
    obtained from the OS until the program ends.

    c) Some operating systems provide (system-specific) facilities
    for allocating memory pages that can later be released under
    program control. The standard C library malloc() and free()
    will not touch this distinct memory... though the OS may provide
    extensions to malloc() and free() that allow this kind of
    memory to participate in malloc() and free()-type of operations.

    d) Operating systems with virtual memory capabilities usually
    keep track of which physical memory has been given to a process at
    the process-table level, which is outside of user control. When the
    process exits, the operating system can be sure of recovering all
    the memory by just releasing its hold on those virtual <-> physical
    memory bindings, not caring what was formally in those pages

    e) non-"hosted" implementations with virtual memory capabilities
    deal with memory however they want, and it is unlikely to be useful
    to worry about the details of free(). Non-hosted implementations
    might not -have- a malloc() or free() as such, as garbage collection
    tends to require non-deterministic time, but non-hosted implementations
    often have hard real-time requirements.
    --
    Prototypes are supertypes of their clones. -- maplesoft
     
    Walter Roberson, Dec 14, 2005
    #4
  5. On Tue, 13 Dec 2005 22:50:10 -0800, siliconwafer wrote:

    > What does free return?


    <quote source = "man -S3 free">
    void free(void* ptr);
    ....
    free() returns no value.
    </quote>

    > i.e how can we be sure that free has freed the
    > exact amount of memory we allocated?


    If you call it appropriatly, all memory assigned to ptr by malloc is
    released. If you don't, undefined behavior is invoked and anything may
    happen.

    > How can we be sure that there is no memory tagged in the machine when we
    > quit the C application?


    If you quit the app, all memory used by that app should be released. If it
    isn't, that's an OS problem. If you worry about memory leaks, there are
    tools (for instance 'valgrind') to check exactly this kind of problems.
     
    Kleuskes & Moos, Dec 14, 2005
    #5
  6. On Wed, 14 Dec 2005 07:35:49 +0000 (UTC), in comp.lang.c ,
    -cnrc.gc.ca (Walter Roberson) wrote:

    >Any "hosted" implementation is going to automatically recover all
    >process memory, whether automatic or call stack or jump stack or
    >file buffer or static or string literals or malloc() or
    >calloc() or executable code or whatever. If it failed to do that,
    >then when a program bombed (e.g., invoked one of the undefined
    >or forbidden behaviours) the memory would be lost and over time
    >all memory would get chewed up, requiring a reboot. So hosted
    >implementations do all the cleanup work anyhow.


    If only this were true. I've seen Windows, Solaris and Linux all give
    me "out of memory" errors because memory wasn't properly reclaimed...

    The point is tho, its a QOI issue and nothing to do with C per se.

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
     
    Mark McIntyre, Dec 14, 2005
    #6
    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. mutant
    Replies:
    0
    Views:
    466
    mutant
    Nov 27, 2005
  2. Greenhorn
    Replies:
    15
    Views:
    881
    Keith Thompson
    Mar 6, 2005
  3. how much does free free?

    , Apr 28, 2007, in forum: C Programming
    Replies:
    13
    Views:
    533
    Giorgos Keramidas
    May 2, 2007
  4. george
    Replies:
    0
    Views:
    1,196
    george
    Aug 29, 2008
  5. mohammed_a_o
    Replies:
    0
    Views:
    319
    mohammed_a_o
    Nov 30, 2010
Loading...

Share This Page