Topic: Corrupted Dynamic Memory
Author: cbarber@bbn.com (Christopher Barber)
Date: 29 Aug 1994 15:09:39 GMT Raw View
>>>>> "RP" == Roberto Pacheco (IE) <pacheco@sunburn.eng.usf.edu> writes:
RP> void main() {
RP> MyClass * objs[2];
RP> for (int i = 0; i < 2; i++)
RP> objs[i] = new MyClass;
RP> ...
RP> delete [] objs;
RP> }
...
RP> The heap memory is corrupted and there is a run-time error:
RP> Floating point error: Stack fault
Take another look at what you are doing when you write "delete [] objs"!
The variable objs is an automatic variable and is most probably allocated
on a stack; it should not be deleted because it wasn't allocated by 'new'.
Trying to delete something that wasn't new'ed caused your heap and stack
corruption.
Only write "delete [] foo" if you previously wrote "foo = new Foo[n]". To
delete the two objects you created you need to delete them each
individually:
delete objs[1] ;
delete objs[2] ;
RP> Finally, I would like to bother you with only one more matter:
RP> I tested the heap memory using the function heapcheck()
RP> (from alloc.h). After some iterations its return is
RP> _HEAPCORRUPT. Questions:
RP> - What can cause this "corruption"?
As explained above, trying to delete something which was not allocated
by new will probably corrupt the heap (and possibly other things as well,
in this case, the stack). Another way to trash the heap is to allocate
memory via new and then write past the end of the allocated space.
RP> - How can I avoid this problem?
Be very careful with allocated memory!
RP> - Is there any function which can "recover"
RP> a corrupted dynamic memory?
No.
BTW, this should have been posted to comp.lang.c++ and not to
comp.std.c++. The latter group is really only for discussion
related to the developing c++ standard.
- Chris
--
Christopher Barber
(cbarber@bbn.com)
Author: pacheco@sunburn.eng.usf.edu (Roberto Pacheco (IE))
Date: 26 Aug 1994 17:50:42 GMT Raw View
Hello C++ Experts!
I have a problem and I was wondering if someone out there
could help me.
I am writing a C++ program with a significant number of
classes. Almost all of them use dynamic memory allocation. The
problem is: when I run the main function like this:
/* --------------------------------------------------
OBS: the creation of a "MyClass" object
fires the allocation of the other
classes in the system
------------------------------------------------- */
void main() {
MyClass * objs[2];
for (int i = 0; i < 2; i++)
objs[i] = new MyClass;
...
delete [] objs;
}
Everything works fine. However, if I use the declarations within
a loop, like this:
void main() {
for (int iterations = 0; iterations < 10; iterations++) {
MyClass * objs[2];
for (int i = 0; i < 2; i++)
objs[i] = new MyClass;
...
delete [] objs;
}
}
The heap memory is corrupted and there is a run-time error:
Floating point error: Stack fault
According to BC++ 4.0 Manual:
> This error may be due to assembly code using too many
> registers or due to a misdeclaration of a floating-point function.
> The program prints the error message and calls abort and _exit.
> These floating-point errors can be avoided by masking the
> exception so that it doesn't occur, or by catching the exception
> with signal.
Before get into assembler code as they suggest, I'd like to answer
some questions:
- Can this error be caused by excessive memory allocation and
not corresponding deallocation?
- If so, by testing all the "new" commands would I supposed to
know if there is or there is not dynamic memory available?
- Since I am testing every allocation, why the program
continues to run even without available memory? (if this is
the case).
Finally, I would like to bother you with only one more matter:
I tested the heap memory using the function heapcheck()
(from alloc.h). After some iterations its return is
_HEAPCORRUPT. Questions:
- What can cause this "corruption"?
- How can I avoid this problem?
- Is there any function which can "recover"
a corrupted dynamic memory?
Well, thank you for having read this message. If you have any
suggestion, it will be more than welcome.
Sincerely,
Roberto Pacheco
pacheco@sunburn.eng.usf.edu
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
I am sorry for this inconvenient.
Once again,
Thank you very much
Roberto Pacheco