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

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

P: n/a
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
Jul 22 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a

"Rob Ristroph" <rg********@gmail.com> wrote in message
news:23**************************@posting.google.c om...
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
Jul 22 '05 #2

P: n/a
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
kb******@gascad.at
Jul 22 '05 #3

P: n/a

"Rob Ristroph" <rg********@gmail.com> wrote in message
news:23**************************@posting.google.c om...
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


Jul 22 '05 #4

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

Jul 22 '05 #5

P: n/a

"Rob Ristroph" <rg********@gmail.com> 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 =---
Jul 22 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.