Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > odd behavior in STL

Reply
Thread Tools

odd behavior in STL

 
 
Ed Platt
Guest
Posts: n/a
 
      07-28-2003
I've been working on a project that uses the STL classes, and twice now
I've run into some odd behavior I can't find the cause of. Basically,
it seems as if a vector is changing its contents by itself. I've tested
the code (C++ in a tcl wrapper) with gcc 2.96 on redhat 7.3 and gcc
2.95.3 on slackware 8.0 and have similar errors on both.

Here is some of the relevant code:

void Graph::update() {
printf("Graph::update()\n");
for (vector<Component*>::iterator iter = myComponents.begin();
iter < myComponents.end();
iter++) {
printf("updating %s(%d)\n", (*iter)->className(), (*iter)->myID());
(*iter)->update();
}
...
printf("updated successfully\n");
}

And here is the output:

graph loaded
Graph::update()
updating Component(3)
updating Component(4)
updating inductor(112)
updating resistor(116)
updating voltage(120)
updating ground(126)
updating junction(127)
updating junction(12
updating junction(129)
updated successfully
updating node(49)
updating capacitor(14)
updating node(15)
updating node(16)
updating node(21)
updating node(22)
updating node(35)
updating node(36)
updating node(43)
updating node(44)
updating node(51)
Segmentation fault

There are a few really strange things about this.

- myComponents is only changed in the function that prints "graph
loaded", if I comment out the part that changes it then the program
doesn't crash.

- update() is usually called as part of a main loop, but the first
output in the output is from a call I added at the end of the function
that changes myComponents to make sure that the right values are getting
put in there (which they are).

- The first call to update() finishes, and another starts, but for some
reason the second one doesn't print "Graph::update()".

- myComponents is a vector<Component*> and although all of the classes
in the output from the first time update() is called are subclasses of
Component, the "node" class is not, but somehow it is in myComponents
the second time update() is called.

The first time I had a similar problem, I ended up using a different
approach, and it just went away. I've looked over every possible thing
I could think of causing this, and I can't find anything. Any ideas or
similar experiences? (Reply to group, email is not valid).

-Ed

 
Reply With Quote
 
 
 
 
Ed Platt
Guest
Posts: n/a
 
      07-28-2003
Thanks. I've made that and all similar changes in the code. I'm still
having the exact same problem though, so let me know if anyone knows of
a possible cause.

-Ed

Xenos wrote:
> You should not use "iter < myComponents.end()". It should read "iter !=
> myComponents.end()"
>
>
> "Ed Platt" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>>I've been working on a project that uses the STL classes, and twice now
>>I've run into some odd behavior I can't find the cause of. Basically,
>>it seems as if a vector is changing its contents by itself. I've tested
>>the code (C++ in a tcl wrapper) with gcc 2.96 on redhat 7.3 and gcc
>>2.95.3 on slackware 8.0 and have similar errors on both.
>>
>>Here is some of the relevant code:
>>
>>void Graph::update() {
>> printf("Graph::update()\n");
>> for (vector<Component*>::iterator iter = myComponents.begin();
>> iter < myComponents.end();
>> iter++) {
>> printf("updating %s(%d)\n", (*iter)->className(), (*iter)->myID());
>> (*iter)->update();
>> }
>> ...
>> printf("updated successfully\n");
>>}
>>
>>And here is the output:
>>
>>graph loaded
>>Graph::update()
>>updating Component(3)
>>updating Component(4)
>>updating inductor(112)
>>updating resistor(116)
>>updating voltage(120)
>>updating ground(126)
>>updating junction(127)
>>updating junction(12
>>updating junction(129)
>>updated successfully
>>updating node(49)
>>updating capacitor(14)
>>updating node(15)
>>updating node(16)
>>updating node(21)
>>updating node(22)
>>updating node(35)
>>updating node(36)
>>updating node(43)
>>updating node(44)
>>updating node(51)
>>Segmentation fault
>>
>>There are a few really strange things about this.
>>
>>- myComponents is only changed in the function that prints "graph
>>loaded", if I comment out the part that changes it then the program
>>doesn't crash.
>>
>>- update() is usually called as part of a main loop, but the first
>>output in the output is from a call I added at the end of the function
>>that changes myComponents to make sure that the right values are getting
>>put in there (which they are).
>>
>>- The first call to update() finishes, and another starts, but for some
>>reason the second one doesn't print "Graph::update()".
>>
>>- myComponents is a vector<Component*> and although all of the classes
>>in the output from the first time update() is called are subclasses of
>>Component, the "node" class is not, but somehow it is in myComponents
>>the second time update() is called.
>>
>>The first time I had a similar problem, I ended up using a different
>>approach, and it just went away. I've looked over every possible thing
>>I could think of causing this, and I can't find anything. Any ideas or
>>similar experiences? (Reply to group, email is not valid).
>>
>>-Ed
>>

>
>
>



 
Reply With Quote
 
 
 
 
John Harrison
Guest
Posts: n/a
 
      07-29-2003

"Ed Platt" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thanks. I've made that and all similar changes in the code. I'm still
> having the exact same problem though, so let me know if anyone knows of
> a possible cause.
>


I think you are going to have to post more code.

john


 
Reply With Quote
 
Ed Platt
Guest
Posts: n/a
 
      07-29-2003
Thanks for the help everyone, I just figured it out. It's rediculously
simple now that I see it, but I suppose things like this tend to be like
that. It turns out that one of the Component pointers being updated
changed myComponents and invalidated the iterator. Here's an
explanation of all the odd behavior:

> - myComponents is only changed in the function that prints "graph
> loaded", if I comment out the part that changes it then the program
> doesn't crash.


This is actually happening inside Graph::update().

> - update() is usually called as part of a main loop, but the first
> output in the output is from a call I added at the end of the function
> that changes myComponents to make sure that the right values are getting
> put in there (which they are).


Because the function that changes myComponents is called in
Graph::update(), the second call to Graph::update() is actually before
the first one has finished.

> - The first call to update() finishes, and another starts, but for some
> reason the second one doesn't print "Graph::update()".


The second call is actually finishing. It has a valid iterator because
it is called after myComponents has changed. Once it returns, the
iterator in the original Graph::update() is invalid and causes the crash.

> - myComponents is a vector<Component*> and although all of the classes
> in the output from the first time update() is called are subclasses of
> Component, the "node" class is not, but somehow it is in myComponents
> the second time update() is called.


Invalid iterator, I wish STL handled things like this better.

-Ed

 
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
Odd behavior with odd code Michael Speer C Programming 33 02-18-2007 07:31 AM
VERY odd routing behavior when attempting VPN connections over Wifi Robert Gordon Wireless Networking 0 08-25-2005 04:04 PM
Firefox under Linux -- odd behavior Dennis J. Tuchler Firefox 0 07-28-2004 04:05 PM
Odd behavior behind the PIX Charles Haron Cisco 1 04-21-2004 04:05 AM
Odd console behavior on Cat 5005 Mike Voss Cisco 0 11-19-2003 10:49 PM



Advertisments