Home | Tutorials | Wiki | Issues
Ask Your Question
0

Still have problem using physics::World::RemoveModel function

asked 2014-08-19 13:35:40 -0500

EdwardC gravatar image

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 ...
(more)
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
5

answered 2015-09-14 07:09:36 -0500

Elte Hupkes gravatar image

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.

edit flag offensive delete link more
Login/Signup to Answer

Question Tools

Stats

Asked: 2014-08-19 13:35:40 -0500

Seen: 1,465 times

Last updated: Sep 14 '15