Stack overflow and memory problem?

Discussion in 'C Programming' started by Yvad, Nov 4, 2005.

  1. Yvad

    Yvad Guest

    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
    Yvad, Nov 4, 2005
    #1
    1. Advertising

  2. >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
    Gordon Burditt, Nov 4, 2005
    #2
    1. Advertising

  3. Yvad

    Zara Guest

    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.

    -- Zara
    Zara, Nov 4, 2005
    #3
  4. Yvad

    Guest

    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, 2005
    #4
  5. EventHelix.com, Nov 4, 2005
    #5
  6. 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.
    Jugoslav Dujic, Nov 4, 2005
    #6
  7. In message <>,
    EventHelix.com <> writes
    >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
    --
    Stephen Kellett
    Object Media Limited http://www.objmedia.demon.co.uk/software.html
    Computer Consultancy, Software Development
    Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
    Stephen Kellett, Nov 4, 2005
    #7
  8. (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
    Lucian Wischik, Nov 4, 2005
    #8
  9. Yvad

    red floyd Guest

    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.
    red floyd, Nov 4, 2005
    #9
  10. In message <>, Lucian Wischik
    <> 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
    Stephen Kellett, Nov 5, 2005
    #10
  11. 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
    Jussi Jumppanen, Nov 9, 2005
    #11
  12. Yvad

    ishekara Guest


    > 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.
    ishekara, Nov 9, 2005
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Yvad
    Replies:
    11
    Views:
    564
    ishekara
    Nov 9, 2005
  2. Dilip
    Replies:
    0
    Views:
    908
    Dilip
    Aug 8, 2006
  3. Une bévue

    regexp and stack overflow

    Une bévue, Mar 27, 2006, in forum: Ruby
    Replies:
    0
    Views:
    94
    Une bévue
    Mar 27, 2006
  4. Kenneth McDonald

    Why stack overflow with such a small stack?

    Kenneth McDonald, Aug 30, 2007, in forum: Ruby
    Replies:
    7
    Views:
    249
    Kenneth McDonald
    Sep 1, 2007
  5. szimek
    Replies:
    4
    Views:
    111
    Thomas 'PointedEars' Lahn
    Feb 17, 2008
Loading...

Share This Page