Stack overflow and memory problem?

When I encounter software crash, the software always pop-up something
like " The instruction at "0x1000a1eb" referenced memory at
"0x000000c0". The memory could not be "read"".
Then Visual C++ will ask me whether to debug the program(in assembly).

My friend told me it is mostly cause by stack overflow. Is he right?
And is there any document on how to debug it?

Advertisements

>When I encounter software crash, the software always pop-up something
>like " The instruction at "0x1000a1eb" referenced memory at
>"0x000000c0". The memory could not be "read"".
>Then Visual C++ will ask me whether to debug the program(in assembly).
>
>My friend told me it is mostly cause by stack overflow. Is he right?
>And is there any document on how to debug it?
>
>And how to avoid this bug in C and C++?

There are a number of reasons you could get a crash like this.
Stack overflow is pretty far down the list.

- Dereferencing NULL pointers
- Dereferencing uninitialized pointers.
- Array subscript out of range
- calling free() on a pointer not returned by malloc(), or free()ing
something twice
- Writing off the end of an array into a pointer variable, which
is then used.

The low value for the memory address referenced suggests the
possibility of dereferencing a NULL pointer to a structure:
((struct foo *)NULL)->bar
but it's difficult to be sure.

Advertisements

On Fri, 04 Nov 2005 07:12:01 -0000, (Gordon
Burditt) wrote:
>>When I encounter software crash, the software always pop-up something
>>like " The instruction at "0x1000a1eb" referenced memory at
>>"0x000000c0". The memory could not be "read"".
>>Then Visual C++ will ask me whether to debug the program(in assembly).
>>
>>My friend told me it is mostly cause by stack overflow. Is he right?
>>And is there any document on how to debug it?
>>
>>And how to avoid this bug in C and C++?
>
>There are a number of reasons you could get a crash like this.
>Stack overflow is pretty far down the list.
>
>- Dereferencing NULL pointers
>- Dereferencing uninitialized pointers.
>- Array subscript out of range
>- calling free() on a pointer not returned by malloc(), or free()ing
> something twice
>- Writing off the end of an array into a pointer variable, which
> is then used.
>
>The low value for the memory address referenced suggests the
>possibility of dereferencing a NULL pointer to a structure:
> ((struct foo *)NULL)->bar
>but it's difficult to be sure.
>
> Gordon L. Burditt

Yes, almost every time I have a crash lihe that ina program, it comes
form dereferencing a NULL pointer.

Gordon Burditt wrote:
|| When I encounter software crash, the software always pop-up something
|| like " The instruction at "0x1000a1eb" referenced memory at
|| "0x000000c0". The memory could not be "read"".
|| Then Visual C++ will ask me whether to debug the program(in assembly).
||
|| My friend told me it is mostly cause by stack overflow. Is he right?
|| And is there any document on how to debug it?
||
|| And how to avoid this bug in C and C++?
|
| There are a number of reasons you could get a crash like this.
| Stack overflow is pretty far down the list.
|
| - Dereferencing NULL pointers
| - Dereferencing uninitialized pointers.

In this particular case, probably dereferencing 0xc0 pointer ,
which is equally fatal as NULL. Also, address of the instruction
suggests that this is probably somewhere in startup code of a Dll
(default base adress 0x10000000).

If you've read those two URLs you'll be aware of memory corruption,
buffer overruns, uninitialised variables and also flow tracing. Two
products that can help with these issues are Memory Validator and Crash
Validator.

Lucian Wischik wrote:
>
> Doesn't VC initialize all variables to 0xc0 in debug mode? so this
> looks like dereferencing an uninitialized pointer.
>
OT, but what the hell... VC initializes to 0xcccccccc in debug mode.

If so just compile the applicaiton with debug information and
run the program in the debugger. The debugger call stack will
show you why the program is crashing.
> And how to avoid this bug in C and C++?

> If you've read those two URLs you'll be aware of memory corruption,
> buffer overruns, uninitialised variables and also flow tracing. Two
> products that can help with these issues are Memory Validator and Crash
> Validator.
>
> http://www.softwareverify.com
>
I think Numega's BoundsChecker is also a good tool to find memory
corruption.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!