Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > strange crashes, maybe related to memory problems, always occur in STL

Reply
Thread Tools

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

 
 
Rob Ristroph
Guest
Posts: n/a
 
      07-02-2004
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
 
Reply With Quote
 
 
 
 
Karl Heinz Buchegger
Guest
Posts: n/a
 
      07-02-2004
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
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
John Harrison
Guest
Posts: n/a
 
      07-02-2004

"Rob Ristroph" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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


 
Reply With Quote
 
Howard
Guest
Posts: n/a
 
      07-02-2004

"Rob Ristroph" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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




 
Reply With Quote
 
Marcin Kalicinski
Guest
Posts: n/a
 
      07-02-2004
> 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





 
Reply With Quote
 
Robbie Hatley
Guest
Posts: n/a
 
      07-03-2004

"Rob Ristroph" <(E-Mail Removed)> 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 =---
 
Reply With Quote
 
Rob Ristroph
Guest
Posts: n/a
 
      07-03-2004
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Strange bug doesn't occur in Pydb kj Python 4 06-12-2008 02:59 PM
Shouldn't server validation always occur when CausesValidation is true?? dustbort ASP .Net 2 02-28-2006 07:45 PM
Of Intrest ? Maybe Yes, Maybe No Old Gringo Computer Support 0 10-11-2004 01:35 AM
Show 4 Records that occur more often...and how often they occur. Miguel Dias Moura ASP .Net 4 05-06-2004 03:40 PM
Some concepts (Maybe LOL maybe not...) C++ 5 08-18-2003 05:48 PM



Advertisments