EDIT: Due to a comment that was right about my example I removed it and turn this into a generic question:
Some times in my projects I come across stack corruption. No matter how much I fight to write code to avoid it, sometimes it is just unavoidable. But when it happens what are the ways to fight it?
I found one macro given by the good fellow in this blog: http://rxwen.blogspot.com/2009/04/detect-stack-corruption.html which reads the ebp register value to detect corruption.
But there are bound to be more sophisticated tools to help with not shooting yourself on the foot. I am programming in Windows using Codeblocks and the gcc compiler. The reason I make this question is to find tools which I can use under my programming environment to help me detect such mistakes and correct them. Any suggestions?
Thanks for any answers and for taking the time to read my question.
When a stack corruption is detected, one should look at the local variables in the called and calling functions to look for possible sources of memory corruption. Check array and pointer declarations for sources of errors. Sometimes stray corruption of a processors registers might also be due to a stack corruption.
If bar keeps a copy of the pointer then anything can happen in the future. Summing up: Stack corruption happens when there's stray pointers pointing to the stack. Save this answer.
Simply set the debugger to execute a breakpoint when a memory location changes, then when the location happens, see what code is executing. This technique can work very well if the location that is being corrupted contains data that is relatively static.
What is stack overflow? A stack overflow is a type of buffer overflow error that occurs when a computer program tries to use more memory space in the call stack than has been allocated to that stack.
It's far from unclear that you are having stack corruption. But I accept there is some data corruption.
A reasonably effective technique is to add guard fields around the suspect field(s):
...
long namecheck1;
Artist artist;
long namecheck2;
...
Have the constructor initialize these to most anything, but without knowing the nature of the corruption something non-zero seems more satisfying.
myclass::myclass() : namecheck1(0x12345678), namcheck2(0x12345678) ...
Add a consistency check member function:
void myclass::isokay()
{
if (namecheck1 != namecheck2 ||
namecheck2 != 0x12345678)
cerr << "the object is corrupted";
... // maybe wait for input, cause core dump, etc.
}
Then pepper the code with calls to this, especially near suspicious logic. If you are comfortable with a debugger, place a breakpoint on the error message. By unraveling the stack, you can ascertain what the program has done recently and gather clues as to what bit of code is probably writing outside the proper bounds.
Valgrind finds all kinds of memory corruption.
GCC has mudflap (-fmudflap
and friends) and -fstack-protector
to catch memory access problems. Other compilers probably do, too.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With