heap corruption

[finding83]

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 */
}

 

[Richard Herring]

In message

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 */
}

 

[red floyd]

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.

 

[Juha Nieminen]

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

 

[tni]

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

 

[James Kanze]

In message

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.

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]

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