physics::Base::childrenEnd causes failures with libc++

[osrf-migration]

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Now that gazebo compiles on OSX 10.9, I've been testing it, and it isn't able to successfully load worlds. It appears to have problems with Base::childrenEnd, which seems to be a cached copy of Base::children.end(). This is referenced in numerous places in Entity.cc and Base.cc:

$ grep -rnI childrenEnd .
./gazebo/physics/Entity.cc:147:  for (iter = this->children.begin(); iter != this->childrenEnd; ++iter)
./gazebo/physics/Entity.cc:279:            iter != this->childrenEnd; ++iter)
./gazebo/physics/Entity.cc:313:      iter != this->childrenEnd; ++iter)
./gazebo/physics/Entity.cc:425:         iter != this->childrenEnd; ++iter)
./gazebo/physics/Entity.cc:441:         iter != this->childrenEnd; ++iter)
./gazebo/physics/Base.hh:309:      protected: Base_V::iterator childrenEnd;
./gazebo/physics/Base.cc:63:       iter != this->childrenEnd; ++iter)
./gazebo/physics/Base.cc:69:  this->childrenEnd = this->children.end();
./gazebo/physics/Base.cc:110:  for (iter = this->children.begin(); iter != this->childrenEnd; ++iter)
./gazebo/physics/Base.cc:115:  this->childrenEnd = this->children.end();
./gazebo/physics/Base.cc:130:  for (iter = this->children.begin(); iter != this->childrenEnd; ++iter)
./gazebo/physics/Base.cc:199:  this->childrenEnd = this->children.end();
./gazebo/physics/Base.cc:206:  for (iter = this->children.begin(); iter != this->childrenEnd; ++iter)
./gazebo/physics/Base.cc:215:  this->childrenEnd = this->children.end();
./gazebo/physics/Base.cc:251:  for (iter = this->children.begin(); iter != this->childrenEnd; ++iter)
./gazebo/physics/Base.cc:263:  this->childrenEnd = this->children.end();
./gazebo/physics/Base.cc:270:  this->childrenEnd = this->children.end();
./gazebo/physics/Base.cc:299:  Base_V::const_iterator iterEnd = this->childrenEnd;
./gazebo/physics/Base.cc:346:  for (iter = this->children.begin(); iter != this->childrenEnd; ++iter)
./gazebo/physics/Base.cc:356:  for (iter = this->children.begin(); iter != this->childrenEnd; ++iter)
./gazebo/physics/Base.cc:380:  for (iter = this->children.begin(); iter != this->childrenEnd; ++iter)

The problems arise in for loops with iter != this->childrenEnd. Switching to iter != this->children.end() appears to fix it. It seems like a bug to me. If it's an optimization, we should profile it and make sure it's worth the effort.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

To clarify, the failures I'm referring to are seg-faults.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

see pull request #857

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

• set assignee_account_id to "557058:5de38267-b118-494c-aa76-4fab35448816"
• set assignee to "scpeters (Bitbucket: scpeters, GitHub: scpeters)"

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Here's a backtrace from running gzserver built from the 1.9 branch with build type RelWithDebInfo.

Core file '/cores/core.35043' (x86_64) was loaded.
Process 0 stopped
* thread #1: tid = 0x0000, 0x00000001045f29e0 libgazebo_physics.1.dylib`gazebo::physics::Base::SetWorld(boost::shared_ptr<gazebo::physics::World> const&) [inlined] boost::shared_ptr<gazebo::physics::Base>::operator->(this=0x0000000000000000) const + 2 at shared_ptr.hpp:653, stop reason = signal SIGSTOP
    frame #0: 0x00000001045f29e0 libgazebo_physics.1.dylib`gazebo::physics::Base::SetWorld(boost::shared_ptr<gazebo::physics::World> const&) [inlined] boost::shared_ptr<gazebo::physics::Base>::operator->(this=0x0000000000000000) const + 2 at shared_ptr.hpp:653
   650 	    // never throws (but has a BOOST_ASSERT in it, so not marked with BOOST_NOEXCEPT)
   651 	    typename boost::detail::sp_member_access< T >::type operator-> () const 
   652 	    {
-> 653 	        BOOST_ASSERT( px != 0 );
   654 	        return px;
   655 	    }
   656 	    
...
(lldb) bt
* thread #1: tid = 0x0000, 0x00000001045f29e0 libgazebo_physics.1.dylib`gazebo::physics::Base::SetWorld(boost::shared_ptr<gazebo::physics::World> const&) [inlined] boost::shared_ptr<gazebo::physics::Base>::operator->(this=0x0000000000000000) const + 2 at shared_ptr.hpp:653, stop reason = signal SIGSTOP
    frame #0: 0x00000001045f29e0 libgazebo_physics.1.dylib`gazebo::physics::Base::SetWorld(boost::shared_ptr<gazebo::physics::World> const&) [inlined] boost::shared_ptr<gazebo::physics::Base>::operator->(this=0x0000000000000000) const + 2 at shared_ptr.hpp:653
    frame #1: 0x00000001045f29de libgazebo_physics.1.dylib`gazebo::physics::Base::SetWorld(this=0x00007fe835cbbf50, _newWorld=<unavailable>) + 110 at Base.cc:382
    frame #2: 0x000000010467aec2 libgazebo_physics.1.dylib`gazebo::physics::World::Load(this=0x00007fe832831400, _sdf=<unavailable>) + 5506 at World.cc:214
    frame #3: 0x00000001046662eb libgazebo_physics.1.dylib`gazebo::physics::load_world(_world=<unavailable>, _sdf=<unavailable>) + 59 at PhysicsIface.cc:119
    frame #4: 0x00000001041e3df2 gzserver`gazebo::Server::LoadImpl(this=0x00007fe8325179b0, _elem=<unavailable>, _physics=<unavailable>) + 1618 at Server.cc:367
    frame #5: 0x00000001041e2c6f gzserver`gazebo::Server::LoadFile(this=0x00007fe8325179b0, _filename=<unavailable>, _physics=0x00007fff5ba2e160) + 511 at Server.cc:290
    frame #6: 0x00000001041e23a3 gzserver`gazebo::Server::ParseArgs(this=0x00007fe8325179b0, argc=1, argv=0x00007fe832517a30) + 8915 at Server.cc:247
    frame #7: 0x00000001041ddc24 gzserver`main(argc=<unavailable>, argv=<unavailable>) + 500 at server_main.cc:40
    frame #8: 0x00007fff970565fd libdyld.dylib`start + 1
    frame #9: 0x00007fff970565fd libdyld.dylib`start + 1
(lldb) 

It points to Base.cc:382, which is the line inside the loop that contains (*iter)->SetWorld(this->world); in the Base::SetWorld function.

void Base::SetWorld(const WorldPtr &_newWorld)
{
  this->world = _newWorld;

  Base_V::iterator iter;
  for (iter = this->children.begin(); iter != this->childrenEnd; ++iter)
  {
    (*iter)->SetWorld(this->world);
  }
}

Seeing the failure in this loop made me suspect that iter != this->childrenEnd could be problematic. Replacing childrenEnd with children.end() fixes the problem in my testing on Mavericks and led to pull request #857.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

• changed state from "new" to "resolved"

pull request #857

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Note that I missed on in pull request #857, but it will be fixed by pull request #881

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• set version to "all"

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• changed state from "resolved" to "closed"