By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,870 Members | 1,224 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,870 IT Pros & Developers. It's quick & easy.

Stack overflow and memory problem?

P: n/a
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

Nov 4 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
>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
Nov 4 '05 #2

P: n/a
On Fri, 04 Nov 2005 07:12:01 -0000, go***********@burditt.org (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.

-- Zara
Nov 4 '05 #3

P: n/a
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

Nov 4 '05 #4

P: n/a
The crash you are experiencing could be due to any number of reasons.

The following articles might help:

http://www.eventhelix.com/RealtimeMa...re_crashes.htm

http://www.eventhelix.com/RealtimeMa..._crashes_2.htm

--
EventStudio System Designer 2.5 - http://www.EventHelix.com/EventStudio
Sequence Diagram Based System Design and Object Modeling Tool

Nov 4 '05 #5

P: n/a
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.
Nov 4 '05 #6

P: n/a
In message <11**********************@g47g2000cwa.googlegroups .com>,
EventHelix.com <ev********@gmail.com> writes
The crash you are experiencing could be due to any number of reasons.

The following articles might help:

http://www.eventhelix.com/RealtimeMa...re_crashes.htm

http://www.eventhelix.com/RealtimeMa...ing_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
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
Nov 4 '05 #7

P: n/a
go***********@burditt.org (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).

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

--
Lucian
Nov 4 '05 #8

P: n/a
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.
Nov 4 '05 #9

P: n/a
In message <qi********************************@4ax.com>, Lucian Wischik
<lu***@wischik.com> writes
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
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
Nov 5 '05 #10

P: n/a
Yvad wrote:
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
Nov 9 '05 #11

P: n/a

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.
Nov 9 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.