RViz segfaults on startup
RViz crashes in 60% of the startsups with a segfault. I tried the RViz and TF2 versions from debians and from source. Also I tried with and without a config file.
Seems like the segfaults originates from somewhere out of a dedicated transform listener thread.
Where could I search more deeper for a solution? Any hints are welcome.
Here are two different stacktraces:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd6e5b700 (LWP 13142)]
0x00007ffff459cfc0 in boost::signals2::detail::signal0_impl<void, boost::signals2::optional_last_value<void>, int, std::less<int>, boost::function<void ()>, boost::function<void (boost::signals2::connection const&)>, boost::signals2::mutex>::nolock_cleanup_connections_from(bool, std::_List_iterator<boost::shared_ptr<boost::signals2::detail::connection_body<std::pair<boost::signals2::detail::slot_meta_group, boost::optional<int> >, boost::signals2::slot0<void, boost::function<void ()> >, boost::signals2::mutex> > > const&, unsigned int) const () from /opt/ros/indigo/lib/libroscpp.so
(gdb) bt
#0 0x00007ffff459cfc0 in boost::signals2::detail::signal0_impl<void, boost::signals2::optional_last_value<void>, int, std::less<int>, boost::function<void ()>, boost::function<void (boost::signals2::connection const&)>, boost::signals2::mutex>::nolock_cleanup_connections_from(bool, std::_List_iterator<boost::shared_ptr<boost::signals2::detail::connection_body<std::pair<boost::signals2::detail::slot_meta_group, boost::optional<int> >, boost::signals2::slot0<void, boost::function<void ()> >, boost::signals2::mutex> > > const&, unsigned int) const () from /opt/ros/indigo/lib/libroscpp.so
#1 0x00007ffff459e89b in boost::signals2::detail::signal0_impl<void, boost::signals2::optional_last_value<void>, int, std::less<int>, boost::function<void ()>, boost::function<void (boost::signals2::connection const&)>, boost::signals2::mutex>::operator()() () from /opt/ros/indigo/lib/libroscpp.so
#2 0x00007fffef27efb2 in boost::signals2::signal0<void, boost::signals2::optional_last_value<void>, int, std::less<int>, boost::function<void ()>, boost::function<void (boost::signals2::connection const&)>, boost::signals2::mutex>::operator()() (this=0x1f093c0) at /usr/include/boost/signals2/detail/signal_template.hpp:695
#3 0x00007fffef276776 in tf2::BufferCore::testTransformableRequests (this=0x1f09250)
at /home/iki/rviz_ws/src/geometry_experimental/tf2/src/buffer_core.cpp:1376
#4 0x00007fffef272d25 in tf2::BufferCore::setTransform (this=0x1f09250, transform_in=..., authority=...,
is_static=false) at /home/iki/rviz_ws/src/geometry_experimental/tf2/src/buffer_core.cpp:265
#5 0x00007fffef5bbb6b in tf2_ros::TransformListener::subscription_callback_impl (this=0x1f09490, msg_evt=...,
is_static=false) at /home/iki/rviz_ws/src/geometry_experimental/tf2_ros/src/transform_listener.cpp:119
#6 0x00007fffef5bb95c in tf2_ros::TransformListener::subscription_callback (this=0x1f09490, msg_evt=...)
at /home/iki/rviz_ws/src/geometry_experimental/tf2_ros/src/transform_listener.cpp:95
#7 0x00007fffef5c41c8 in boost::_mfi::mf1<void, tf2_ros::TransformListener, ros::MessageEvent<tf2_msgs::TFMessage_<std::allocator<void> > const> const&>::operator() (this=0x1f099f8, p=0x1f09490, a1=...)
at /usr/include/boost/bind/mem_fn_template.hpp:165
#8 0x00007fffef5c367f in boost::_bi::list2<boost::_bi::value<tf2_ros::TransformListener*>, boost::arg<1> >::operator()<boost::_mfi::mf1<void, tf2_ros::TransformListener, ros::MessageEvent<tf2_msgs::TFMessage_<std::allocator<void> > const> const&>, boost::_bi::list1<boost::shared_ptr<tf2_msgs::TFMessage_<std::allocator<void> > const> const&> > (this=0x1f09a08,
f=..., a=...) at /usr/include/boost/bind/bind.hpp:313
#9 0x00007fffef5c2b2e in boost::_bi::bind_t<void, boost::_mfi::mf1<void, tf2_ros::TransformListener, ros::MessageEvent<tf2_msgs::TFMessage_<std::allocator<void> > const> const&>, boost::_bi::list2<boost::_bi::value<tf2_ros::TransformListener*>, boost::arg<1> > >::operator()<boost::shared_ptr<tf2_msgs::TFMessage_<std ...
These tracebacks are very different parts of code, both of which are heavily used by almost every user. As such I would guess that there is something overwriting their memory space. I'd suggest trying out a memory debugging tool to see if they can catch anything.
Are you running inside of
rqt
or are you using any custom rviz plugins?@William No I run it with
rosrun rviz rviz
and no custom plugins. I deleted the~/.rviz
folder to eliminate config problems but this didn't help. So our RViz crashes with default config and with our MoveIt! config. Now I'll try the memory tools.