Help | Site Map
Connecting Tech Pros Worldwide
 
 
LinkBack Thread Tools
  #1  
Old July 19th, 2005, 04:49 PM
Ed Platt
Guest
 
Posts: n/a
Default odd behavior in STL

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(128)
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

  #2  
Old July 19th, 2005, 04:49 PM
Ed Platt
Guest
 
Posts: n/a
Default Re: odd behavior in STL

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:[color=blue]
> You should not use "iter < myComponents.end()". It should read "iter !=
> myComponents.end()"
>
>
> "Ed Platt" <nospam@mudbrick.mit.edu> wrote in message
> news:3F256720.2020101@mudbrick.mit.edu...
>[color=green]
>>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(128)
>>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
>>[/color]
>
>
>[/color]


  #3  
Old July 19th, 2005, 04:50 PM
John Harrison
Guest
 
Posts: n/a
Default Re: odd behavior in STL


"Ed Platt" <nospam@mudbrick.mit.edu> wrote in message
news:3F259E45.2020409@mudbrick.mit.edu...[color=blue]
> 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.
>[/color]

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

john


  #4  
Old July 19th, 2005, 04:51 PM
Ed Platt
Guest
 
Posts: n/a
Default Re: odd behavior in STL

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:
[color=blue]
> - 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.[/color]

This is actually happening inside Graph::update().
[color=blue]
> - 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).[/color]

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.
[color=blue]
> - The first call to update() finishes, and another starts, but for some
> reason the second one doesn't print "Graph::update()".[/color]

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.
[color=blue]
> - 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.[/color]

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

-Ed

 

Bookmarks

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 Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

What is Bytes?

We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights. Get the best answers to your questions from over network members.
Post your question now . . .
It's fast and it's free

Popular Articles