strange crashes, maybe related to memory problems, always occur in STL

Discussion in 'C++' started by Rob Ristroph, Jul 2, 2004.

  1. Rob Ristroph

    Rob Ristroph Guest

    Hi,

    It's pretty unhelpful to post "I have a huge piece of code that
    crashes in strange places, what's the problem?" but that's basically
    my problem and I really am at my wit's end.

    The piece of code in question always crashes in an STL operation
    such as a vector.push_back, but the location of the crash changes as I
    change how various parts are handled in memory, i.e., make some things
    dynamically allocated instead of new'd. I know this is a typical
    symptom of doing something bad with memory; however the piece of code
    is part of a web server and it is difficult to run it through valgrind
    because it is not launched from the command line.

    Given that pretty vague discription, maybe someone can still
    give me some general suggestions ?

    --Rob
    Rob Ristroph, Jul 2, 2004
    #1
    1. Advertising

  2. Re: strange crashes, maybe related to memory problems, always occur inSTL

    Rob Ristroph wrote:
    >
    > Hi,
    >
    > It's pretty unhelpful to post "I have a huge piece of code that
    > crashes in strange places, what's the problem?" but that's basically
    > my problem and I really am at my wit's end.
    >
    > The piece of code in question always crashes in an STL operation
    > such as a vector.push_back, but the location of the crash changes as I
    > change how various parts are handled in memory, i.e., make some things
    > dynamically allocated instead of new'd. I know this is a typical
    > symptom of doing something bad with memory; however the piece of code
    > is part of a web server and it is difficult to run it through valgrind
    > because it is not launched from the command line.
    >
    > Given that pretty vague discription, maybe someone can still
    > give me some general suggestions ?


    Problems like these are of the hardest kind to diagnose.
    Watch out for
    dangling pointers
    uninitialized variables
    out of bounds array accesses
    strange casts

    The problem in debugging is:
    The actual code error might not even be related with the code position
    where you see the crash.

    Strip down the program as far as you can. Isolate functionalty into standalone
    programs, doing code reviews and tests until you know that those modules are
    not the source of your problem. Expect that your actual problem is in code
    you thought to be 100% bug free. Trust nobody and questionize each and
    every statement.
    And finally: Have some luck

    Good luck to you

    --
    Karl Heinz Buchegger
    Karl Heinz Buchegger, Jul 2, 2004
    #2
    1. Advertising

  3. "Rob Ristroph" <> wrote in message
    news:...
    > Hi,
    >
    > It's pretty unhelpful to post "I have a huge piece of code that
    > crashes in strange places, what's the problem?" but that's basically
    > my problem and I really am at my wit's end.
    >
    > The piece of code in question always crashes in an STL operation
    > such as a vector.push_back, but the location of the crash changes as I
    > change how various parts are handled in memory, i.e., make some things
    > dynamically allocated instead of new'd. I know this is a typical
    > symptom of doing something bad with memory; however the piece of code
    > is part of a web server and it is difficult to run it through valgrind
    > because it is not launched from the command line.
    >
    > Given that pretty vague discription, maybe someone can still
    > give me some general suggestions ?
    >


    Could you not write a command line program that 'hosts' this piece of code?
    Then you can use valgrind (whatever that is). Arguably this is the first
    thing you should have done before you started on the code itself.

    john
    John Harrison, Jul 2, 2004
    #3
  4. Rob Ristroph

    Howard Guest

    "Rob Ristroph" <> wrote in message
    news:...
    > Hi,
    >
    > It's pretty unhelpful to post "I have a huge piece of code that
    > crashes in strange places, what's the problem?" but that's basically
    > my problem and I really am at my wit's end.
    >
    > The piece of code in question always crashes in an STL operation
    > such as a vector.push_back, but the location of the crash changes as I
    > change how various parts are handled in memory, i.e., make some things
    > dynamically allocated instead of new'd.


    Dynamically allocated *is* new'd. :)

    > I know this is a typical
    > symptom of doing something bad with memory; however the piece of code
    > is part of a web server and it is difficult to run it through valgrind
    > because it is not launched from the command line.
    >


    Not sure what "valgrind" is.

    Can you run the program from your IDE, in debug mode? If not, how about
    outputting (via cout or cerr) at key points in the code?

    I've had crashes with push_back before. I probably should write these down
    when I solve them, but if I can recall, there were several types of errors
    that (I think) led to these in my recent experience.

    For one, watch out especially for overwriting an array (such as declaring
    int a[10] and then assigning to a[10], even though a[9] is the last legal
    element of that array). This nasty bug often makes apparently good code
    crash, because the memory just beyond that array (especially if it's a local
    array) may easily be actual code sitting on the stack. So when the code
    gets executed, it's trash. Anything can happen! (Another reason this type
    of error is nasty is that often it works FINE in your debug builds, but
    crashes in release builds.)

    Another to watch for is passing invalid data to the push_back call. If
    you're passing an object to the push_back call, make sure you have a valid
    copy constructor for its class defined (if the default won't do). If you're
    passing a pointer, make sure it's a valid pointer, and that what it points
    to is not going to go out of scope or otherwise be destroyed while the
    vector still has a pointer to it.

    Also, if your code acts in any way like a "state machine", make doubly
    certain that you properly initialize the state. For example, if you ever
    have checks that a pointer is not NULL, make sure that you *set* the pointer
    to NULL after destroying what it points to, and also make sure it *starts
    out* as either NULL or pointing to a valid object. It really sucks to find
    out that there is one obscure way to initialize your "state machine" that
    never calls your initialization code, and that one way doesn't occur until
    you release your "working" code, only to have a bunch of customers complain
    of crashes. This actually happened to me. :-( Triple-check all
    assumptions!!!

    A debugging method that often helps in these situations is to comment out a
    bunch of code...stuff that you'll need in the end but that you might be able
    to get by without in order to test. Removing code like that can often make
    your software stop crashing. Then start adding back code, just a little at
    a time if possible, until the crash returns. When it begins crashing again,
    you've got a clue. Now, that does NOT mean the code you just added *causes*
    the crash! But it *is* a clue, nonetheless. If that code looks fine, check
    what its dependencies are. Suppose, for example, it uses a parameter
    variable. Trace back to all ways that that parameter can be passed to your
    function. You may find that you're passing the parameter incorrectly in one
    case. Or that there's one case where you might pass a NULL pointer. In any
    case, you've narrowed your search now.

    These are just some of the things I do when I come across a problem like
    this that isn't immediately obvious. Try them out. And good hunting! :)

    -Howard
    Howard, Jul 2, 2004
    #4
  5. > Hi,
    >
    > It's pretty unhelpful to post "I have a huge piece of code that
    > crashes in strange places, what's the problem?" but that's basically
    > my problem and I really am at my wit's end.
    >
    > The piece of code in question always crashes in an STL operation
    > such as a vector.push_back, but the location of the crash changes as I
    > change how various parts are handled in memory, i.e., make some things
    > dynamically allocated instead of new'd. I know this is a typical
    > symptom of doing something bad with memory; however the piece of code
    > is part of a web server and it is difficult to run it through valgrind
    > because it is not launched from the command line.
    >
    > Given that pretty vague discription, maybe someone can still
    > give me some general suggestions ?
    >
    > --Rob


    Don't keep pointers/iterators to elements of std::vector if you resize it.
    Vector might be reallocated and moved, and your pointers are bogus. This is
    one among thousands of possible causes, but in the past this happened to me
    so often that right now it's always the first thing that comes to my mind.

    Good luck,
    Marcin
    Marcin Kalicinski, Jul 2, 2004
    #5
  6. "Rob Ristroph" <> wrote:

    > ... The piece of code in question always crashes in an STL operation
    > such as a vector.push_back, but the location of the crash changes as I
    > change how various parts are handled in memory, i.e., make some things
    > dynamically allocated instead of new'd. I know this is a typical
    > symptom of doing something bad with memory; however the piece of code
    > is part of a web server and it is difficult to run it through valgrind
    > because it is not launched from the command line. ...


    I'm disturbed by "dynamically allocated instead of new'd".
    The new operator IS the C++ dynamic allocation operator.

    I've a few suggestions, in addtion to the excellent ones
    given by others on this thread so far:

    1. Be sure everything new'ed eventually gets delete'ed
    2. Be sure nothing NOT new'ed is accidentally delete'ed
    3. Don't confuse delete with delete[]

    May seem obvious, but sometimes the hardest bugs are
    caused by things that should have been obvious.


    --
    Cheers,
    Robbie Hatley
    Tustin, CA, USA
    email: lonewolfintj at pacbell dot net
    web: home dot pacbell dot net slant earnur slant






    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
    Robbie Hatley, Jul 3, 2004
    #6
  7. Rob Ristroph

    Rob Ristroph Guest

    I'd like to thank everyone who responded. I've collected a list of
    all the suggestions of things to look for, and we will probably spend
    a day going over the code "by hand" checking for the various things.

    If that doesn't work, we'll have to make a wrapper program that runs
    it from the command line so that we can debug it more normally,
    probably using valgrind. (The valgrind page is
    http://valgrind.kde.org/, for those who didn't know what it was; I
    have found it very useful in tracking down these types of problems in
    the past, to the point where I hesitate to incorporate code from third
    parties into my projects until it has been run through it with many
    different inputs.)

    The reason that this code was not developed with each modular piece
    being tested standalone from the command line with it's own test
    main(), is that this project is any attempt to rewrite portions of a
    slow web based system written in PHP, which is slow, into faster C++
    code which can be provided to the PHP language as native functions
    through PHP extension mechanism. Testing some of this stuff without
    the webserver means writing a lot of wrapper code, and replicating
    specific test cases from a web page to a command line that repeats the
    conditions is involved. Not impossible, just involved enough so that
    we put it off too long ;)

    Thanks again for all the tips.

    --Rob
    Rob Ristroph, Jul 3, 2004
    #7
    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. Miguel Dias Moura
    Replies:
    4
    Views:
    452
    Hans Kesting
    May 6, 2004
  2. dustbort
    Replies:
    2
    Views:
    2,839
    dustbort
    Feb 28, 2006
  3. Guest
    Replies:
    5
    Views:
    610
  4. Ville Vainio
    Replies:
    11
    Views:
    606
    Hamish Lawson
    Aug 10, 2004
  5. kj
    Replies:
    4
    Views:
    321
Loading...

Share This Page