Rob Ristroph said:
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
