Stack overflow and memory problem?

[Yvad]

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++?

All the best,
Davy

 

[Gordon Burditt]

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

 

[Zara]

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.

-- Zara

 

[tony_in_da_uk]

Gordon's listed many plausible causes. Further, try adding debug
information to your program, and you shouldn't have to look at it in
assembly, making it much easier to understand the error. Tony

 

[EventHelix.com]

The crash you are experiencing could be due to any number of reasons.

The following articles might help:

http://www.eventhelix.com/RealtimeMantra/Basics/debugging_software_crashes.htm

http://www.eventhelix.com/RealtimeMantra/Basics/debugging_software_crashes_2.htm

 

[Jugoslav Dujic]

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

<I'm not sure why clc and clc++ are in newsgroup list>

--
Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

 

[Stephen Kellett]

The crash you are experiencing could be due to any number of reasons.

The following articles might help:

http://www.eventhelix.com/RealtimeMantra/Basics/debugging_software_crashes.htm

http://www.eventhelix.com/RealtimeMantra/Basics/debugging_software_c
rashes_2.htm

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

Stephen

 

[Lucian Wischik]

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.

Doesn't VC initialize all variables to 0xc0 in debug mode? so this
looks like dereferencing an uninitialized pointer.

Isn't it funny how they put "read" in quotes, as if "reading" memory
were some esoteric concept?!

 

[red floyd]

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.

 

[Stephen Kellett]

Doesn't VC initialize all variables to 0xc0 in debug mode? so this
looks like dereferencing an uninitialized pointer.

Static variables. 0x00000000 (I think)
CRT variables: 0xcdcdcdcd
Win32 Heap variables 0xbaadf00d
Stack Variables: 0xcccccccc

Stephen

 

[Jussi Jumppanen]

My friend told me it is mostly cause by stack overflow. Is he right?
No.

And is there any document on how to debug it?

I assume you have the source code.

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++?

Don't write buggy code

Jussi Jumppanen
Author of: Zeus for Windows, Win32 (Brief, WordStar, Emacs) Text Editor
"The C/C++, Java, HTML, FTP, Python, PHP, Perl folding editor"
http://www.zeusedit.com

 

[ishekara]

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.