Robot3d crashes on adding robot over YARP

Bug #681714 reported by Anne van Rossum
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Robot3D
Fix Committed
High
Anne van Rossum

Bug Description

Gdb does not report so much about the crash, valgrind gives this additional information:

Info: 23:19:24:<AddRobot:247>Component "DefaultArenaComponent" loaded
==3546== Invalid read of size 4
==3546== at 0x42EB6B9: dtGame::GameManager::DoSendMessageToComponents(dtGame::Message const&) (in /usr/lib/libdtGame.so)
==3546== by 0x42ECE9B: dtGame::GameManager::DoSendMessage(dtGame::Message const&) (in /usr/lib/libdtGame.so)

...

==3546== Address 0xb6bad40 is 8 bytes inside a block of size 32 free'd
==3546== at 0x4024851: operator delete(void*) (vg_replace_malloc.c:387)
==3546== by 0x42F37AC: std::vector<dtCore::RefPtr<dtGame::GMComponent>, std::allocator<dtCore::RefPtr<dtGame::GMComponent> > >::
  _M_insert_aux(__gnu_cxx::__normal_iterator<dtCore::RefPtr<dtGame::GMComponent>*, std::vector<dtCore::RefPtr<dtGame::GMComponent>, std::allocator<dtCore::RefPtr<dtGame::GMComponent> > > >,
  dtCore::RefPtr<dtGame::GMComponent> const&) (in /usr/lib/libdtGame.so)
==3546== by 0x42E5BD6: dtGame::GameManager::AddComponent(dtGame::GMComponent&, dtGame::GameManager::ComponentPriority const&) (in /usr/lib/libdtGame.so)
==3546== by 0xBA6C01D: srInterface::YarpedSim::AddController(ControllerInitData const&) (YarpedSim.cpp:286)
==3546== by 0xBA6B3F6: srInterface::YarpedSim::AddRobot(std::string const&, std::string const&, int const&, osg::Vec3f const&) (YarpedSim.cpp:214)
==3546== by 0xBA6A85E: srInterface::YarpedSim::ProcessMessage(dtGame::Message const&) (YarpedSim.cpp:150)
==3546== by 0x42EB6DA: dtGame::GameManager::DoSendMessageToComponents(dtGame::Message const&) (in /usr/lib/libdtGame.so)

...

==3546== Invalid read of size 4
==3546== at 0x42EB6CF: dtGame::GameManager::DoSendMessageToComponents(dtGame::Message const&) (in /usr/lib/libdtGame.so)
==3546== by 0x42ECE9B: dtGame::GameManager::DoSendMessage(dtGame::Message const&) (in /usr/lib/libdtGame.so)

...

==3546== Address 0x0 is not stack'd, malloc'd or (recently) free'd

==3546== Process terminating with default action of signal 11 (SIGSEGV)
==3546== Access not within mapped region at address 0x0
==3546== at 0x42EB6CF: dtGame::GameManager::DoSendMessageToComponents(dtGame::Message const&) (in /usr/lib/libdtGame.so)
==3546== by 0x42ECE9B: dtGame::GameManager::DoSendMessage(dtGame::Message const&) (in /usr/lib/libdtGame.so)

Revision history for this message
Anne van Rossum (annevanrossum) wrote :

The problem stems from the way Delta3D is set up. It might perhaps be called an actual bug... The actors in Delta3D can be created and removed on the fly. The components in Delta3D cannot. At least, if you add a component this should happen OUTSIDE of the ProcessMessage loop of another component.

It is namely the case that AddComponent invalidates the iterators in DoSendMessageToComponents calling either ProcessMessage multiple times on the same component, or worse, finding no component anymore at that location because the iterators have become invalid because of memory reallocation. This bug could only be reproduced by me in a 32-bit VM, and not on the 64-bit host, which might relate to either the different system libraries or more limited system resources.

The bug has been circumvented by using a separate thread to handle YARP messages like "ADD_ROBOT", sending a "pause simulator" game message, waiting till the component gets this message, sleeping a bit additionally (assuming that this would be enough to get this message to all components) and finally adding the component to the Robot3D simulator.

This bug might resurface when many robots are used (each with their own component).

More information: http://www.delta3d.org/forum/viewtopic.php?forum=14&showtopic=19848

Changed in robot3d:
status: New → Fix Committed
importance: Undecided → High
assignee: nobody → Anne van Rossum (annevanrossum)
status: Fix Committed → Fix Released
status: Fix Released → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.