heap corruption

Discussion in 'C++' started by finding83, Jul 30, 2009.

  1. finding83

    finding83 Guest

    why is it a problem if we have a huge piece of code between new and
    delete of a char array.
    example:
    http://www.efnetcpp.org/wiki/Heap_Corruption


    void this_is_bad() /* You wouldn't believe how often this kind of
    code can be found */
    {
    char *p = new char[5]; /* spend some cycles in the memory
    manager */
    /* do some stuff with p */
    delete[] p; /* spend some more cycles, and create an
    opportunity for a leak */
    }
    finding83, Jul 30, 2009
    #1
    1. Advertising

  2. In message
    <>,
    finding83 <> writes
    >why is it a problem if we have a huge piece of code between new and
    >delete of a char array.


    Consider what happens if that huge piece of code throws an exception, or
    causes the function to return early.

    >example:
    >http://www.efnetcpp.org/wiki/Heap_Corruption
    >
    >
    > void this_is_bad() /* You wouldn't believe how often this kind of
    >code can be found */
    > {
    > char *p = new char[5]; /* spend some cycles in the memory
    >manager */
    > /* do some stuff with p */
    > delete[] p; /* spend some more cycles, and create an
    >opportunity for a leak */
    > }


    Did you notice the parallel piece of code on that page?:

    void this_is_good()
    {
    /* Avoid allocation of small temporary objects on the heap*/
    char p[5]; /* Use the stack instead */
    /* do some stuff */
    }


    --
    Richard Herring
    Richard Herring, Jul 30, 2009
    #2
    1. Advertising

  3. finding83

    red floyd Guest

    On Jul 30, 9:37 am, finding83 <> wrote:
    > why is it a problem if we have a huge piece of code between new and
    > delete of a char array.
    > example:http://www.efnetcpp.org/wiki/Heap_Corruption
    >
    >  void this_is_bad() /* You wouldn't believe how often this kind of
    > code can be found */
    >  {
    >    char *p = new char[5];    /* spend some cycles in the memory
    > manager */
    >    /* do some stuff with p */
    >    delete[] p;      /* spend some more cycles, and create an
    > opportunity for a leak */
    >  }


    Because "/* do some stuff with p */" may throw an exception. In that
    case, p is leaked.
    Use std::vector instead.
    red floyd, Jul 30, 2009
    #3
  4. Richard Herring wrote:
    > /* Avoid allocation of small temporary objects on the heap*/
    > char p[5]; /* Use the stack instead */


    Why small only? Larger arrays will also be more efficient when
    stack-allocated rather than heap-allocated (stack allocation is
    extremely fast, while heap allocation is very heavy).

    (OTOH that might be referring to most programs having a stack size
    limit, which might get triggered if the array is too large. OTOH I would
    be surprised if the stack limit is not in the hundreds of megabytes in
    most systems. Certainly no need to worry whether your array has 5 or 5
    million elements.)
    Juha Nieminen, Jul 30, 2009
    #4
  5. finding83

    tni Guest

    Juha Nieminen wrote:
    > Richard Herring wrote:
    >> /* Avoid allocation of small temporary objects on the heap*/
    >> char p[5]; /* Use the stack instead */

    >
    > Why small only? Larger arrays will also be more efficient when
    > stack-allocated rather than heap-allocated (stack allocation is
    > extremely fast, while heap allocation is very heavy).
    >
    > (OTOH that might be referring to most programs having a stack size
    > limit, which might get triggered if the array is too large. OTOH I would
    > be surprised if the stack limit is not in the hundreds of megabytes in
    > most systems. Certainly no need to worry whether your array has 5 or 5
    > million elements.)


    The default thread stack size isn't that big, 1MB on Windows, 64kb on
    BSD, 2MB on Linux/x86. Putting large stuff on the stack is asking for
    trouble.
    tni, Jul 30, 2009
    #5
  6. finding83

    James Kanze Guest

    On Jul 30, 7:09 pm, Richard Herring <junk@[127.0.0.1]> wrote:
    > In message
    > <>,
    > finding83 <> writes


    > >why is it a problem if we have a huge piece of code between
    > >new and delete of a char array.


    > Consider what happens if that huge piece of code throws an
    > exception, or causes the function to return early.


    Which still won't result in heap corruption.

    > >example:
    > >http://www.efnetcpp.org/wiki/Heap_Corruption


    The page really isn't that good.

    > > void this_is_bad() /* You wouldn't believe how often this kind of
    > >code can be found */
    > > {
    > > char *p = new char[5]; /* spend some cycles in the memory
    > >manager */
    > > /* do some stuff with p */
    > > delete[] p; /* spend some more cycles, and create an
    > >opportunity for a leak */
    > > }


    > Did you notice the parallel piece of code on that page?:


    > void this_is_good()
    > {
    > /* Avoid allocation of small temporary objects on the heap*/
    > char p[5]; /* Use the stack instead */
    > /* do some stuff */
    > }


    If the problem in the bad example is heap corruption (which the
    title of the page certainly suggests), about all the good
    version changes is to replace heap corruption with stack
    corruption. The "good" solution here is to use std::string (or
    std::vector< char >). Which uses (or may use, in the case of
    std::string) the heap, but does so in a controlled manner---good
    implementations of std::vector or std::string will bounds check,
    for example, and prevent corruption.

    The only thing the change in the cited page does is prevent a
    possible memory leak. Certainly a worthwhile change, but
    nothing to do with heap corruption.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 31, 2009
    #6
  7. finding83

    James Kanze Guest

    On Jul 30, 11:19 pm, tni <> wrote:
    > Juha Nieminen wrote:
    > > Richard Herring wrote:
    > >> /* Avoid allocation of small temporary objects on the heap*/
    > >> char p[5]; /* Use the stack instead */


    > > Why small only? Larger arrays will also be more efficient
    > > when stack-allocated rather than heap-allocated (stack
    > > allocation is extremely fast, while heap allocation is very
    > > heavy).


    > > (OTOH that might be referring to most programs having a
    > > stack size limit, which might get triggered if the array is
    > > too large. OTOH I would be surprised if the stack limit is
    > > not in the hundreds of megabytes in most systems. Certainly
    > > no need to worry whether your array has 5 or 5 million
    > > elements.)


    > The default thread stack size isn't that big, 1MB on Windows,
    > 64kb on BSD, 2MB on Linux/x86. Putting large stuff on the
    > stack is asking for trouble.


    It depends. Nothing says you have to restrict yourself to the
    default stack size. (Under Linux, you can specify unlimited,
    which means something around 3 GB, minus whatever other memory
    you use.)

    On the other hand, accessing a couple of million elements will
    doubtlessly take so much time that the cost of the dynamic
    access will be negligible. And all of the "safe" data
    structures for large data in C++ (today) do use the stack. The
    only reason you'd declare a C style array on the stack is
    because the profiler said you were spending too much time in the
    allocator for std::vector, and this is not likely to be
    significant unless the actual size of the vector was fairly
    small.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 31, 2009
    #7
    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. Replies:
    2
    Views:
    3,790
    Walter
    Apr 29, 2005
  2. Walter Roberson

    My MSVC 6 DLL now has HEAP corruption problems

    Walter Roberson, May 11, 2005, in forum: C Programming
    Replies:
    2
    Views:
    437
    Flash Gordon
    May 12, 2005
  3. Riley DeWiley
    Replies:
    2
    Views:
    762
    Jim Langston
    Jun 27, 2005
  4. Martin the Third
    Replies:
    8
    Views:
    363
    Kai-Uwe Bux
    Jun 13, 2008
  5. mohangupta13

    cause of heap corruption here??

    mohangupta13, Sep 12, 2009, in forum: C Programming
    Replies:
    3
    Views:
    377
    Barry Schwarz
    Sep 13, 2009
Loading...

Share This Page