Still have problem using physics::World::RemoveModel function
Hi
I saw the post: http://answers.gazebosim.org/question/6706/gazebo-aborts-with-boostlock_error-when-removing-a/
So I updated my gazebo to 4.0, which is installed from the Debian package. When I tried to use RemoveModel function, I got two types of errors.
At the beginning, the error is:
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >'
what(): boost: mutex lock failed in pthread_mutex_lock: Invalid argument
The backtrace information is:
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffdb912700 (LWP 5670)]
0x00007ffff4f1cf89 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff4f1cf89 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff4f20398 in __GI_abort () at abort.c:89
#2 0x00007ffff55226b5 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff5520836 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff5520863 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff5520aa2 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007ffff7695301 in ?? () from /usr/lib/x86_64-linux-gnu/libgazebo_transport.so.4
#7 0x00007ffff7695485 in ?? () from /usr/lib/x86_64-linux-gnu/libgazebo_transport.so.4
#8 0x00007ffff76ade30 in gazebo::transport::Publisher::OnPublishComplete(unsigned int) () from /usr/lib/x86_64-linux-gnu/libgazebo_transport.so.4
#9 0x00007ffff76888ba in gazebo::transport::Connection::OnWrite(boost::system::error_code const&) () from /usr/lib/x86_64-linux-gnu/libgazebo_transport.so.4
#10 0x00007ffff7699848 in ?? () from /usr/lib/x86_64-linux-gnu/libgazebo_transport.so.4
#11 0x00007ffff7699be3 in ?? () from /usr/lib/x86_64-linux-gnu/libgazebo_transport.so.4
#12 0x00007ffff76969de in ?? () from /usr/lib/x86_64-linux-gnu/libgazebo_transport.so.4
#13 0x00007ffff76a5a66 in ?? () from /usr/lib/x86_64-linux-gnu/libgazebo_transport.so.4
#14 0x00007ffff5c43a4a in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0
#15 0x00007ffff6a78182 in start_thread (arg=0x7fffdb912700) at pthread_create.c:312
#16 0x00007ffff4fe138d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Later I received different type of error message for the same code:
gzserver: /usr/include/boost/smart_ptr/shared_ptr.hpp:653: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = gazebo::physics::Entity; typename boost::detail::sp_member_access<T>::type = gazebo::physics::Entity*]: Assertion `px != 0' failed.
The backtrace information is:
Program received signal SIGABRT, Aborted.
0x00007ffff4f1cf89 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff4f1cf89 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff4f20398 in __GI_abort () at abort.c:89
#2 0x00007ffff4f15e46 in __assert_fail_base (fmt=0x7ffff50677b8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7ffff70aa6e1 "px != 0",
file=file@entry=0x7ffff70aaab0 "/usr/include/boost/smart_ptr/shared_ptr.hpp", line=line@entry=653,
function=function@entry=0x7ffff70ad120 "typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = gazebo::physics::Entity; typename boost::detail::sp_member_access<T>::type = gazebo::physics::Entit"...) at assert.c:92
#3 0x00007ffff4f15ef2 in __GI___assert_fail (assertion=0x7ffff70aa6e1 "px != 0", file=0x7ffff70aaab0 "/usr/include/boost/smart_ptr/shared_ptr.hpp", line=653,
function=0x7ffff70ad120 "typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = gazebo::physics::Entity; typename boost::detail::sp_member_access<T>::type = gazebo::physics::Entit"...) at assert.c:101
#4 0x00007ffff70538dc in ?? () from /usr/lib/x86_64-linux-gnu/libgazebo_sensors.so.4
#5 0x00007ffff706be5e in gazebo::sensors::ContactSensor::Fini() () from /usr/lib/x86_64-linux-gnu/libgazebo_sensors.so.4
#6 0x00007ffff709e442 in gazebo::sensors::SensorManager::SensorContainer::RemoveSensor(std::string const&) () from /usr/lib/x86_64-linux-gnu/libgazebo_sensors.so.4
#7 0x00007ffff709ea08 in gazebo::sensors::SensorManager::Update(bool) () from /usr/lib/x86_64-linux-gnu/libgazebo_sensors.so.4
#8 0x000000000041130f in gazebo::Server::Run() ()
#9 0x000000000040cffb in ?? ()
#10 0x00007ffff4f07ec5 in __libc_start_main (main=0x40cf30, argc=3, argv=0x7fffffffdf78, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdf68) at libc-start.c:287
#11 0x000000000040ee18 in _start ()
I am not sure what is going on, any help will be appreciate!
Asked by EdwardC on 2014-08-19 13:35:40 UTC
Answers
Since I've been investigating issues like these quite thoroughly I figured I'd answer this year old question for people like me who come looking for it.
Basically, removing models on any other thread than the world thread results in a lot of race conditions, all the time. For instance, removing a model while a scene message is being built might lead to the scene message trying to access a now deleted element, resulting in segfaults, null pointers, you name it. I still don't have enough knowledge of the entire system to know what all the possibilities are but I'm sure there's more. Not to mention the memory leaks associated with deleting models... It seems the delete model scenario is not used very often, or these issues would be more prominent (and probably already fixed).
Anyway, if like me you really do need to delete models often, I suggest avoiding doing it directly. You can make sure deleting the model happens on the main thread by sending an entity_delete message to the system rather than calling World::RemoveModel(). That will circumvent at least some of the problems.
Asked by Elte Hupkes on 2015-09-14 07:09:36 UTC
Comments