Shared Memory Segments may be unmapped or unlinkced while in use

[hg-zt]

Hi, I'm using ros2 with fastdds as the middleware.

For data sharing publishers and subscribers, when the publisher is shutdown (Ctrl-C or SIGKILL), subscribers sometimes crash with segfault.
By tracing with GDB, /proc/{pid}/maps and /dev/shm, I found the mapped memory could be unmapped (munmap is called and the mapping disappeared from proc/{pid}/maps) or unlinked (disappeared in /dev/shm) even if the subscriber callback which is using the data has not finished.

The backtrace for munmap

#0  munmap () at ../sysdeps/unix/syscall-template.S:78
#1  0x0000007f9f74f240 in boost::interprocess::mapped_region::priv_close() () from /opt/ros/humble/lib/libfastrtps.so.2.6
#2  0x0000007f9f74f444 in eprosima::fastdds::rtps::SharedSegment<boost::interprocess::basic_managed_shared_memory<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, unsign
ed int, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>,boost::interprocess::shared_memory_object>::~SharedSegment() () from /opt/ros/humble/lib/libfastrtps.so.2.6 
#3  0x0000007f9f78cad4 in eprosima::fastrtps::rtps::ReaderPool::~ReaderPool() () from /opt/ros/humble/lib/libfastrtps.so.2.6
#4  0x0000007f9f712d58 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() () from /opt/ros/humble/lib/libfastrtps.so.2.6 
#5  0x0000007f9f7926f4 in eprosima::fastrtps::rtps::DataSharingListener::remove_datasharing_writer(eprosima::fastrtps:
:rtps::GUID_t const&) () from /opt/ros/humble/lib/libfastrtps.so.2.6                      
#6  0x0000007f9f7a1234 in eprosima::fastrtps::rtps::StatefulReader::matched_writer_remove(eprosima::fastrtps::rtps::GU
ID_t const&, bool) () from /opt/ros/humble/lib/libfastrtps.so.2.6
#7  0x0000007f9f9aaff8 in eprosima::fastrtps::rtps::EDP::unpairWriterProxy(eprosima::fastrtps::rtps::GUID_t const&, ep
rosima::fastrtps::rtps::GUID_t const&, bool) () from /opt/ros/humble/lib/libfastrtps.so.2.6
#8  0x0000007f9f99a19c in eprosima::fastrtps::rtps::PDP::removeWriterProxyData(eprosima::fastrtps::rtps::GUID_t const&
) () from /opt/ros/humble/lib/libfastrtps.so.2.6
#9  0x0000007f9f9bdf40 in eprosima::fastrtps::rtps::EDPSimplePUBListener::onNewCacheChangeAdded(eprosima::fastrtps::rt
ps::RTPSReader*, eprosima::fastrtps::rtps::CacheChange_t const*) () from /opt/ros/humble/lib/libfastrtps.so.2.6
#10 0x0000007f9f79d26c in eprosima::fastrtps::rtps::StatefulReader::NotifyChanges(eprosima::fastrtps::rtps::WriterProx
y*) () from /opt/ros/humble/lib/libfastrtps.so.2.6
#11 0x0000007f9f79d380 in eprosima::fastrtps::rtps::StatefulReader::change_received(eprosima::fastrtps::rtps::CacheCha
nge_t*, eprosima::fastrtps::rtps::WriterProxy*, unsigned long) () from /opt/ros/humble/lib/libfastrtps.so.2.6
#12 0x0000007f9f7a47b0 in eprosima::fastrtps::rtps::StatefulReader::processDataMsg(eprosima::fastrtps::rtps::CacheChan
ge_t*) () from /opt/ros/humble/lib/libfastrtps.so.2.6
#13 0x0000007f9f7bf770 in eprosima::fastrtps::rtps::MessageReceiver::process_data_message_without_security(eprosima::f
astrtps::rtps::EntityId_t const&, eprosima::fastrtps::rtps::CacheChange_t&) () from /opt/ros/humble/lib/libfastrtps.so
.2.6
#14 0x0000007f9f7c8a80 in eprosima::fastrtps::rtps::MessageReceiver::proc_Submsg_Data(eprosima::fastrtps::rtps::CDRMes
sage_t*, eprosima::fastrtps::rtps::SubmessageHeader_t*) const () from /opt/ros/humble/lib/libfastrtps.so.2.6

The profile

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">

   <data_writer profile_name="default publisher profile" is_default_profile="true">
       <qos>
           <publishMode>
               <kind>ASYNCHRONOUS</kind>
           </publishMode>
           <data_sharing>
               <kind>AUTOMATIC</kind>
           </data_sharing>
       </qos>
       <historyMemoryPolicy>PREALLOCATED_WITH_REALLOC</historyMemoryPolicy>
   </data_writer>

   <data_reader profile_name="default subscription profile" is_default_profile="true">
       <qos>
           <data_sharing>
               <kind>AUTOMATIC</kind>
           </data_sharing>
       </qos>
       <historyMemoryPolicy>PREALLOCATED_WITH_REALLOC</historyMemoryPolicy>
   </data_reader>
</profiles>

I'm not sure if its a dds issue or ros2 issue. I guess there should be some reference-counting mechanisms (shared_ptr) for keeping the mapping valid while in use instead of releasing the segments immediately when the writer status is changed?