heap corruption
finding83
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
<a0ce4c30-9a1b-4ed0...@z4g2000prh.googlegroups.com>,
finding83 <find...@gmail.com> 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
red floyd
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
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
> <a0ce4c30-9a1b-4ed0-9ded-9b3ff8c85...@z4g2000prh.googlegroups.com>,
> finding83 <findin...@gmail.com> 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:james...@gmail.com
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
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.