Do I need to free all memory that is malloced?

Discussion in 'C Programming' started by karthik.nar@gmail.com, Sep 24, 2005.

  1. Guest

    suppose i have

    char* ip = malloc(10);

    and i use up only two bytes.

    then can i free(ip+2)

    the idea is that in case my program does not use up all the bytes
    malloced, am i allowed to free up the unused bytes alone?
     
    , Sep 24, 2005
    #1
    1. Advertising

  2. Guest

    Use realloc(ip, 2)
     
    , Sep 24, 2005
    #2
    1. Advertising

  3. <> wrote in message
    news:...
    > suppose i have
    > char* ip = malloc(10);
    > and i use up only two bytes.
    > then can i free(ip+2)
    >
    > the idea is that in case my program does not use up all the bytes
    > malloced, am i allowed to free up the unused bytes alone?


    free (ip+2) is wrong. It shouldn't normally bring the system down, but it
    will neither free *ip nor part of *ip.

    There're only two ways:
    1. free exactly what (as much as) you've allocated
    2. reallocate (with realloc()) the block to make it bigger or smaller

    Alex
     
    Alexei A. Frounze, Sep 24, 2005
    #3
  4. Bryan Donlan Guest

    Alexei A. Frounze wrote:

    > <> wrote in message
    > news:...
    >> suppose i have
    >> char* ip = malloc(10);
    >> and i use up only two bytes.
    >> then can i free(ip+2)
    >>
    >> the idea is that in case my program does not use up all the bytes
    >> malloced, am i allowed to free up the unused bytes alone?

    >
    > free (ip+2) is wrong. It shouldn't normally bring the system down, but it
    > will neither free *ip nor part of *ip.


    On the contrary, it is very likely to cause the system to crash or some kind
    of malloc asserts to be tripped. It's common to have some sort of pointer
    immediately before a mallocced memory block, or at least a size indicator.

    --
    λz.λi.i(i((λn.λm.λz.λi.nz(λq.mqi))((λn.λz.λi.n(nzi)i)(λz.λi.i(((λn.λz.λi.n
    (nzi)i)(λz.λi.i(iz)))zi)))((λn.λz.λi.n(nzi)i)(λz.λi.i(iz)))zi))
     
    Bryan Donlan, Sep 25, 2005
    #4
  5. "Bryan Donlan" <> wrote in message
    news:...
    > Alexei A. Frounze wrote:

    ....
    > > free (ip+2) is wrong. It shouldn't normally bring the system down, but

    it
    > > will neither free *ip nor part of *ip.

    >
    > On the contrary, it is very likely to cause the system to crash or some

    kind
    > of malloc asserts to be tripped. It's common to have some sort of pointer
    > immediately before a mallocced memory block, or at least a size indicator.


    The system will only crash if the user memory manager is dumb and there's no
    memory protection employed in the CPU. On x86 the system (windows or linux)
    won't crash if the user app does something like free(ip+2). On such a
    system, the maximum problem that one may get is an exception and maybe
    program termination.

    As for the user memory manager (or libc's malloc/free), some sanity checks
    are due anyway. The mm must check whether the pointer falls inside the range
    of the address space where the memory is managed, whether the pointer points
    to a beginning of a valid and allocated block. It shouldn't be very hard to
    perform these checks. Even if an implementation of the mm does not catch all
    100% of mm-related problems, many of them will be caught. If the control
    information cannot be protected from the damage, some CRC-aided cheks will
    help at least determine whether or not the control info is still valid.
    If someone tells this would degrade the performance I'd agree, but then
    again, a question naturally arises... Is the algorithm picked in the app
    good enough at all if it's too dependent on the mm speed?

    If we assume dumb programmers and their apps (actually, that should be
    assumed as even experienced and good programmers sometimes do bad things,
    most often accidentally and not because they didn't know something), we must
    provide more or less stable and error-detecting basis for them, i.e. the
    standard libraries, etc.

    Alex
     
    Alexei A. Frounze, Sep 25, 2005
    #5
  6. wrote on 24/09/05 :
    > suppose i have
    >
    > char* ip = malloc(10);
    >
    > and i use up only two bytes.
    >
    > then can i free(ip+2)
    >
    > the idea is that in case my program does not use up all the bytes
    > malloced, am i allowed to free up the unused bytes alone?


    No. The value to be passed to free() must be exactly match the value
    received from malloc().

    However, the allocated bloc can be shriked with realloc(). Be sure you
    have alot of byte to spare because realloc() isn't cheap...

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

    I once asked an expert COBOL programmer, how to
    declare local variables in COBOL, the reply was:
    "what is a local variable?"
     
    Emmanuel Delahaye, Sep 25, 2005
    #6
  7. Bryan Donlan Guest

    Alexei A. Frounze wrote:

    > "Bryan Donlan" <> wrote in message
    > news:...
    >> Alexei A. Frounze wrote:

    > ...
    >> > free (ip+2) is wrong. It shouldn't normally bring the system down, but

    > it
    >> > will neither free *ip nor part of *ip.

    >>
    >> On the contrary, it is very likely to cause the system to crash or some

    > kind
    >> of malloc asserts to be tripped. It's common to have some sort of pointer
    >> immediately before a mallocced memory block, or at least a size
    >> indicator.

    >
    > The system will only crash if the user memory manager is dumb and there's
    > no memory protection employed in the CPU. On x86 the system (windows or
    > linux) won't crash if the user app does something like free(ip+2). On such
    > a system, the maximum problem that one may get is an exception and maybe
    > program termination.


    Well, okay, that's what I meant with crash. GNU libc actively aborts the
    program when it detects this.

    --
    λz.λi.i(i((λn.λm.λz.λi.nz(λq.mqi))((λn.λz.λi.n(nzi)i)(λz.λi.i(((λn.λz.λi.n
    (nzi)i)(λz.λi.i(iz)))zi)))((λn.λz.λi.n(nzi)i)(λz.λi.i(iz)))zi))
     
    Bryan Donlan, Sep 26, 2005
    #7
  8. Richard Bos Guest

    "Alexei A. Frounze" <> wrote:

    > <> wrote in message
    > news:...
    > > suppose i have
    > > char* ip = malloc(10);
    > > and i use up only two bytes.
    > > then can i free(ip+2)
    > >
    > > the idea is that in case my program does not use up all the bytes
    > > malloced, am i allowed to free up the unused bytes alone?

    >
    > free (ip+2) is wrong. It shouldn't normally bring the system down,


    Very nearly nothing a mere user program does will bring a modern,
    well-written OS down. Bringing your program down is another matter.

    > but it will neither free *ip nor part of *ip.


    You don't know that; it causes undefined behaviour. Undefined behaviour
    is allowed to do anything, and anything does include "appearing to
    work". It also includes terminating the program with some kind of access
    violation fault (while, of course, leaving the rest of the system
    perfectly undisturbed), and in fact that may be the most common result.

    > There're only two ways:
    > 1. free exactly what (as much as) you've allocated
    > 2. reallocate (with realloc()) the block to make it bigger or smaller


    And free() each realloc()ated block only once - do not free() both the
    original _and_ the new pointer. In fact, once you've called realloc()
    succesfully, forget about the original pointer entirely.

    Richard
     
    Richard Bos, Sep 26, 2005
    #8
  9. On Sun, 25 Sep 2005 22:51:09 +0200, Emmanuel Delahaye wrote:
    <snip>
    > However, the allocated bloc can be shriked with realloc(). Be sure you
    > have alot of byte to spare because realloc() isn't cheap...


    Can you expound on this a little? Is the memory used by realloc()
    at any one time substantially greater than the old allocation
    plus the new allocation? And isn't the old allocation freed?
     
    Charles Sullivan, Sep 26, 2005
    #9
  10. Charles Sullivan wrote on 26/09/05 :
    > On Sun, 25 Sep 2005 22:51:09 +0200, Emmanuel Delahaye wrote:
    > <snip>
    >> However, the allocated bloc can be shriked with realloc(). Be sure you
    >> have alot of byte to spare because realloc() isn't cheap...

    >
    > Can you expound on this a little? Is the memory used by realloc()
    > at any one time substantially greater than the old allocation
    > plus the new allocation? And isn't the old allocation freed?


    If you are to spare just a few bytes, don't call realloc(). It costs in
    terms of
    - development (the good use of realloc() is not trivial, see the FAQ)
    - time execution (realloc() can be a slow function)

    Not to mention that in most cases, the gain is close to 0 because the
    'internal memory blocks' have a minimum size (say 32 or 64 bytes). It's
    all a matter of implementation.



    --
    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, Sep 26, 2005
    #10
  11. On Mon, 26 Sep 2005 11:20:38 GMT, in comp.lang.c ,
    (Richard Bos) wrote:

    >Very nearly nothing a mere user program does will bring a modern,
    >well-written OS down.


    That the funniest thing I've heard this year!

    Dont try this at home
    $ sudo root
    $ rm -rf /

    (root is a user too, you know...)
    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

    ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-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, Sep 26, 2005
    #11
  12. Mark McIntyre <> writes:
    > On Mon, 26 Sep 2005 11:20:38 GMT, in comp.lang.c ,
    > (Richard Bos) wrote:
    >
    >>Very nearly nothing a mere user program does will bring a modern,
    >>well-written OS down.

    >
    > That the funniest thing I've heard this year!
    >
    > Dont try this at home
    > $ sudo root
    > $ rm -rf /
    >
    > (root is a user too, you know...)


    $ sudo root
    sudo: root: command not found

    But yes, I see what you mean.

    All you've done here is illustrate the difference between "very nearly
    nothing" and "nothing".

    It would be more accurate to say that very nearly nothing a user
    program running without elevated privileges does will bring down a
    modern OS. There are, of course, exceptions (OS bugs,
    denial-of-service attacks, etc.).

    The narrower point here is that calling free() with an invalid pointer
    (e.g., "p = malloc(whatever); free(p+2);") is likely to crash the
    individual program, but is highly unlikely to crash the entire OS.

    But that's far beyond anything the C standard guarantees, or even
    discusses. There may or may not even be an OS. Either way, an
    invalid free() invokes undefined behavior; if it *does* crash the OS,
    it's the OS's fault, not C's fault.

    --
    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, Sep 26, 2005
    #12
  13. Richard Bos Guest

    Mark McIntyre <> wrote:

    > On Mon, 26 Sep 2005 11:20:38 GMT, in comp.lang.c ,
    > (Richard Bos) wrote:
    >
    > >Very nearly nothing a mere user program does will bring a modern,
    > >well-written OS down.

    >
    > That the funniest thing I've heard this year!
    >
    > Dont try this at home
    > $ sudo root
    > $ rm -rf /
    >
    > (root is a user too, you know...)


    "Very nearly nothing" and "a mere user program" do kinda imply "not
    actively suicidal", really.

    Richard
     
    Richard Bos, Sep 27, 2005
    #13
  14. Ian Malone Guest

    Emmanuel Delahaye wrote:
    > Charles Sullivan wrote on 26/09/05 :
    >
    >> On Sun, 25 Sep 2005 22:51:09 +0200, Emmanuel Delahaye wrote:
    >> <snip>
    >>
    >>> However, the allocated bloc can be shriked with realloc(). Be sure
    >>> you have alot of byte to spare because realloc() isn't cheap...

    >>
    >>
    >> Can you expound on this a little? Is the memory used by realloc()
    >> at any one time substantially greater than the old allocation
    >> plus the new allocation? And isn't the old allocation freed?

    >
    >
    > If you are to spare just a few bytes, don't call realloc(). It costs in
    > terms of
    > - development (the good use of realloc() is not trivial, see the FAQ)


    The only reference I can see in the clc faq is to passing null
    to realloc. The only gotcha I'm aware off with respect to realloc
    is the need to check the return value before changing the pointer,
    so it requires a temporary variable. That seems fairly trivial.

    > - time execution (realloc() can be a slow function)
    >


    This is certainly true on implementations I've used,
    I would guess shrinking is faster than expanding
    (probably no need to move and therefore no need to
    copy the allocated memory). 100% implementation
    dependant of course.

    > Not to mention that in most cases, the gain is close to 0 because the
    > 'internal memory blocks' have a minimum size (say 32 or 64 bytes). It's
    > all a matter of implementation.
    >


    Indeed, I'm not sure realloc is even guaranteed to free
    the released memory for further use[1]. Whether it's
    worth doing probably depends on your overestimation
    of the array size.

    [1] Except in this case: "If the realloc function returns a
    null pointer when size is zero and ptr is not a null
    pointer, the object it pointed to has been freed."

    --
    imalone
     
    Ian Malone, Sep 27, 2005
    #14
  15. In article <4all.nl>,
    Richard Bos <> wrote:
    > "Alexei A. Frounze" <> wrote:
    > >
    > > free (ip+2) is wrong. It shouldn't normally bring the system down,

    >
    > Very nearly nothing a mere user program does will bring a modern,
    > well-written OS down.


    int main(void)
    {
    while(1)
    {
    malloc(1000000);
    fork();
    }
    }

    /* Sure, it's not conforming, but neither is free(ip+2). */
     
    Anonymous 7843, Sep 27, 2005
    #15
  16. "Anonymous 7843" <> wrote in message
    news:gAf_e.16345$mH.15336@fed1read07...
    > int main(void)
    > {
    > while(1)
    > {
    > malloc(1000000);
    > fork();
    > }
    > }
    > /* Sure, it's not conforming, but neither is free(ip+2). */


    Even w/o fork() it can be very bad (depends on the system) and yet be
    conforming...

    Alex
     
    Alexei A. Frounze, Sep 27, 2005
    #16
  17. embedhere Guest

    Ian Malone wrote:
    > Emmanuel Delahaye wrote:
    > > Charles Sullivan wrote on 26/09/05 :
    > >
    > >> On Sun, 25 Sep 2005 22:51:09 +0200, Emmanuel Delahaye wrote:
    > >> <snip>
    > >>
    > >>> However, the allocated bloc can be shriked with realloc(). Be sure
    > >>> you have alot of byte to spare because realloc() isn't cheap...
    > >>
    > >>
    > >> Can you expound on this a little? Is the memory used by realloc()
    > >> at any one time substantially greater than the old allocation
    > >> plus the new allocation? And isn't the old allocation freed?

    > >
    > >
    > > If you are to spare just a few bytes, don't call realloc(). It costs in
    > > terms of
    > > - development (the good use of realloc() is not trivial, see the FAQ)

    >
    > The only reference I can see in the clc faq is to passing null
    > to realloc. The only gotcha I'm aware off with respect to realloc
    > is the need to check the return value before changing the pointer,
    > so it requires a temporary variable. That seems fairly trivial.
    >
    > > - time execution (realloc() can be a slow function)
    > >

    >
    > This is certainly true on implementations I've used,
    > I would guess shrinking is faster than expanding
    > (probably no need to move and therefore no need to
    > copy the allocated memory). 100% implementation
    > dependant of course.
    >
    > > Not to mention that in most cases, the gain is close to 0 because the
    > > 'internal memory blocks' have a minimum size (say 32 or 64 bytes). It's
    > > all a matter of implementation.
    > >

    >
    > Indeed, I'm not sure realloc is even guaranteed to free
    > the released memory for further use[1]. Whether it's
    > worth doing probably depends on your overestimation
    > of the array size.
    >
    > [1] Except in this case: "If the realloc function returns a
    > null pointer when size is zero and ptr is not a null
    > pointer, the object it pointed to has been freed."
    >
    > --
    > imalone



    Hello Friends,
    Can somebody come up with a code snippet for the same?
    Thanks,
    Balakrishna
     
    embedhere, Sep 28, 2005
    #17
  18. In article <gAf_e.16345$mH.15336@fed1read07>, (Anonymous 7843) writes:
    > In article <4all.nl>,
    > Richard Bos <> wrote:
    > >
    > > Very nearly nothing a mere user program does will bring a modern,
    > > well-written OS down.

    >
    > int main(void)
    > {
    > while(1)
    > {
    > malloc(1000000);
    > fork();
    > }
    > }
    >
    > /* Sure, it's not conforming, but neither is free(ip+2). */


    That won't cause a problem for a modern, well-written, correctly
    configured OS. Properly configured POSIX systems have reasonable
    resource limits set.

    For that matter, most of the modern POSIX systems I use deal
    relatively well with resource exhaustion - they certainly don't go
    down. They may have to kill off some noncritical processes, but
    the OS itself stays running.

    --
    Michael Wojcik

    Maybe, but it can't compete with _SNA Formats_ for intricate plot
    twists. "This format is used only when byte 5, bit 1 is set to 1
    (i.e., when generalized PIU trace data is included)" - brilliant!
     
    Michael Wojcik, Sep 28, 2005
    #18
  19. In article <>,
    Michael Wojcik <> wrote:
    >
    > In article <gAf_e.16345$mH.15336@fed1read07>,
    > (Anonymous 7843) writes:
    > > In article <4all.nl>,
    > > Richard Bos <> wrote:
    > > >
    > > > Very nearly nothing a mere user program does will bring a modern,
    > > > well-written OS down.

    > >
    > > int main(void)
    > > {
    > > while(1)
    > > {
    > > malloc(1000000);
    > > fork();
    > > }
    > > }
    > >
    > > /* Sure, it's not conforming, but neither is free(ip+2). */

    >
    > That won't cause a problem for a modern, well-written, correctly
    > configured OS. Properly configured POSIX systems have reasonable
    > resource limits set.
    >
    > For that matter, most of the modern POSIX systems I use deal
    > relatively well with resource exhaustion - they certainly don't go
    > down. They may have to kill off some noncritical processes, but
    > the OS itself stays running.


    I've tried out the above snippet on dozens of unix/posix/linux
    machines. You're right, they don't always crash, but more often
    than not the machine is essentially unusable and needs to be
    rebooted. Perhaps it is just my bad luck to encounter only
    incorrectly configured systems; or the number of correctly
    configured systems is lower than ideal.
     
    Anonymous 7843, Sep 28, 2005
    #19
  20. Randy Howard Guest

    Mark McIntyre wrote
    (in article <>):

    > On Mon, 26 Sep 2005 11:20:38 GMT, in comp.lang.c ,
    > (Richard Bos) wrote:
    >
    >> Very nearly nothing a mere user program does will bring a modern,
    >> well-written OS down.

    >
    > That the funniest thing I've heard this year!
    >
    > Dont try this at home
    > $ sudo root
    > $ rm -rf /
    >
    > (root is a user too, you know...)


    $ sudo cat < /dev/zero > /dev/mem

    is pretty exciting, and much faster.

    :)

    --
    Randy Howard (2reply remove FOOBAR)
     
    Randy Howard, Sep 29, 2005
    #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. rohit

    malloced union member

    rohit, May 19, 2004, in forum: C Programming
    Replies:
    10
    Views:
    569
    Richard Bos
    May 24, 2004
  2. Kumar McMillan
    Replies:
    0
    Views:
    426
    Kumar McMillan
    Apr 19, 2007
  3. Replies:
    18
    Views:
    756
  4. Panduranga Chary

    How memory function free() knows how much memory to free.

    Panduranga Chary, Dec 27, 2007, in forum: C Programming
    Replies:
    2
    Views:
    428
    Keith Thompson
    Dec 27, 2007
  5. Noob
    Replies:
    18
    Views:
    370
    Tim Rentsch
    Jun 12, 2013
Loading...

Share This Page