ROS triggers segfault on shutdown

[vmatare]

I've now been looking at the shutdown segfaults for a while because they're starting to annoy me. Most of the time it's this:

Core was generated by `./fawkes -c gazsim-configurations/default/robotino1.yaml -p gazsim-meta-gologpp'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007ff760479a40 in ros::Publication::enqueueMessage(ros::SerializedMessage const&) () from /usr/lib64/libroscpp.so
[Current thread is 1 (Thread 0x7ff7157fa700 (LWP 83542))]
(gdb) bt
#0  0x00007ff760479a40 in ros::Publication::enqueueMessage(ros::SerializedMessage const&) () at /usr/lib64/libroscpp.so
#1  0x00007ff760479d7b in ros::Publication::processPublishQueue() () at /usr/lib64/libroscpp.so
#2  0x00007ff760469128 in ros::TopicManager::processPublishQueues() () at /usr/lib64/libroscpp.so
#3  0x00007ff760476440 in boost::signals2::detail::signal_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()() () at /usr/lib64/libroscpp.so
#4  0x00007ff7604720a9 in ros::PollManager::threadFunc() () at /usr/lib64/libroscpp.so
#5  0x00007ff7c42303de in  () at /usr/lib64/libboost_thread.so.1.71.0
#6  0x00007ff7c506e510 in start_thread (arg=<optimized out>) at pthread_create.c:486
#7  0x00007ff7c52df09f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

My hunch is that it's trying to publish a message that has already been destroyed by some other thread that is shutting down. Should be relatively easy to fix with some synchronization.

[nlimpert]

Does this only happen on your Gentoo setup?

I have tried to reproduce the issue with the following node:

#include "ros/ros.h"
#include "std_msgs/String.h"

#include <sstream>

int main(int argc, char **argv)
{
  ros::init(argc, argv, "talker");
  ros::NodeHandle n;
  ros::Publisher chatter_pub = n.advertise<std_msgs::String>("chatter", 1000);
  ros::Rate loop_rate(10);

  int count = 0;
  while (ros::ok())
  {
    std_msgs::String *msg;
    msg = new std_msgs::String();

    std::stringstream ss;
    ss << "hello world";
    msg->data = ss.str();

    delete msg;

    chatter_pub.publish(*msg);

    ros::spinOnce();

    loop_rate.sleep();
    ++count;
  }


  return 0;
}

This seems to run fine until there is an actual subscriber on the /chatter topic.
When I subscribe to /chatter (e.g. with rostopic echo /chatter) I get the following coredump:

#0  0x00007f85fed9ba78 in __memmove_avx_unaligned_erms () from /lib64/libc.so.6
#1  0x000000000040c33e in ros::serialization::Serializer<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::write<ros::serialization::OStream> (stream=..., str="\274") at /usr/lib64/ros/include/ros/serialization.h:245
#2  0x000000000040c16a in ros::serialization::serialize<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, ros::serialization::OStream> (stream=..., t="\274") at /usr/lib64/ros/include/ros/serialization.h:154
#3  0x000000000040be8a in ros::serialization::OStream::next<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (t="\274", this=0x7ffe016cc9d0) at /usr/lib64/ros/include/ros/serialization.h:747
#4  ros::serialization::Serializer<std_msgs::String_<std::allocator<void> > >::allInOne<ros::serialization::OStream, std_msgs::String_<std::allocator<void> > const&> (stream=..., m=...) at /usr/lib64/ros/include/std_msgs/String.h:160
#5  0x000000000040bb0e in ros::serialization::Serializer<std_msgs::String_<std::allocator<void> > >::write<ros::serialization::OStream, std_msgs::String_<std::allocator<void> > > (stream=..., t=...) at /usr/lib64/ros/include/std_msgs/String.h:163
#6  0x000000000040b798 in ros::serialization::serialize<std_msgs::String_<std::allocator<void> >, ros::serialization::OStream> (stream=..., t=...) at /usr/lib64/ros/include/ros/serialization.h:154
#7  0x000000000040b3dc in ros::serialization::serializeMessage<std_msgs::String_<std::allocator<void> > > (message=...) at /usr/lib64/ros/include/ros/serialization.h:815
#8  0x000000000040c20d in boost::_bi::list1<boost::reference_wrapper<std_msgs::String_<std::allocator<void> > const> >::operator()<ros::SerializedMessage, ros::SerializedMessage (*)(std_msgs::String_<std::allocator<void> > const&), boost::_bi::list0> (this=0x7ffe016cce20, 
    f=@0x7ffe016cce18: 0x40b30f <ros::serialization::serializeMessage<std_msgs::String_<std::allocator<void> > >(std_msgs::String_<std::allocator<void> > const&)>, a=...) at /usr/include/boost/bind/bind.hpp:249
#9  0x000000000040c09e in boost::_bi::bind_t<ros::SerializedMessage, ros::SerializedMessage (*)(std_msgs::String_<std::allocator<void> > const&), boost::_bi::list1<boost::reference_wrapper<std_msgs::String_<std::allocator<void> > const> > >::operator() (this=0x7ffe016cce18) at /usr/include/boost/bind/bind.hpp:1294
#10 0x000000000040bf1b in boost::detail::function::function_obj_invoker0<boost::_bi::bind_t<ros::SerializedMessage, ros::SerializedMessage (*)(std_msgs::String_<std::allocator<void> > const&), boost::_bi::list1<boost::reference_wrapper<std_msgs::String_<std::allocator<void> > const> > >, ros::SerializedMessage>::invoke (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:137
#11 0x00007f85ff6ff658 in ros::TopicManager::publish(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::function<ros::SerializedMessage ()> const&, ros::SerializedMessage&) () from /usr/lib64/ros/lib/libroscpp.so
#12 0x000000000040ae55 in ros::Publisher::publish<std_msgs::String_<std::allocator<void> > > (this=0x7ffe016cd050, message=...) at /usr/lib64/ros/include/ros/publisher.h:119
#13 0x0000000000409681 in main (argc=1, argv=0x7ffe016cd2f8) at /home/nlimpert/dev/catkin_ws/src/beginner_tutorials/src/talker.cpp:25

Line 25 is the chatter_pub.publish(*msg); (I don't know how to apply line numbering within markdown).

I've also found this discussion on ROS Answers which basically recommends to rebuild:
https://answers.ros.org/question/342249/error-with-unknown-segmentation-fault-cause/