Open lexamor opened 1 year ago
Hi @lexamor ,
Unfortunately v2.9 is EOL since July and therefore not maintained anymore. Could you please try to reproduce this on master?
Hi @EduPonz ,
Yes, I am able to reproduce an issue on master (as well on other versions e.g. 2.10.x )
Segfault backtrace
0x000000000022f173: eprosima::fastdds::dds::ParameterProperty_t::second[abi:cxx11]() const at ParameterTypes.hpp:982
0x000000000060e5e9: eprosima::fastdds::dds::ParameterProperty_t::pair[abi:cxx11]() const at ParameterTypes.hpp:1027
0x000000000060b02b: eprosima::fastrtps::rtps::EDPStatic::assignRemoteEndpoints(eprosima::fastrtps::rtps::ParticipantProxyData const&, bool) at EDPStatic.cpp:444 (discriminator 1)
0x00000000005e62ba: eprosima::fastrtps::rtps::PDPSimple::notifyAboveRemoteEndpoints(eprosima::fastrtps::rtps::ParticipantProxyData const&, bool) at PDPSimple.cpp:501
0x000000000036144c: eprosima::fastrtps::rtps::security::SecurityManager::discovered_participant(eprosima::fastrtps::rtps::ParticipantProxyData const&) at SecurityManager.cpp:595
0x00000000005e60c3: eprosima::fastrtps::rtps::PDPSimple::assignRemoteEndpoints(eprosima::fastrtps::rtps::ParticipantProxyData*) at PDPSimple.cpp:465
0x00000000005e992d: eprosima::fastrtps::rtps::PDPListener::onNewCacheChangeAdded(eprosima::fastrtps::rtps::RTPSReader*, eprosima::fastrtps::rtps::CacheChange_t const*) at PDPListener.cpp:184
0x00000000004ad4f6: eprosima::fastrtps::rtps::StatelessReader::change_received(eprosima::fastrtps::rtps::CacheChange_t*) at StatelessReader.cpp:333
0x00000000004ae332: eprosima::fastrtps::rtps::StatelessReader::processDataMsg(eprosima::fastrtps::rtps::CacheChange_t*) at StatelessReader.cpp:557
0x00000000007dda29: eprosima::fastrtps::rtps::MessageReceiver::process_data_message_without_security(eprosima::fastrtps::rtps::EntityId_t const&, eprosima::fastrtps::rtps::CacheChange_t&, bool)::{lambda(eprosima::fastrtps::rtps::RTPSReader*)#1}::operator()(eprosima::fastrtps::rtps::RTPSReader*) const at MessageReceiver.cpp:220
0x00000000007e2f36: void eprosima::fastrtps::rtps::MessageReceiver::findAllReaders<eprosima::fastrtps::rtps::MessageReceiver::process_data_message_without_security(eprosima::fastrtps::rtps::EntityId_t const&, eprosima::fastrtps::rtps::CacheChange_t&, bool)::{lambda(eprosima::fastrtps::rtps::RTPSReader*)#1}>(eprosima::fastrtps::rtps::EntityId_t const&, eprosima::fastrtps::rtps::MessageReceiver::process_data_message_without_security(eprosima::fastrtps::rtps::EntityId_t const&, eprosima::fastrtps::rtps::CacheChange_t&, bool)::{lambda(eprosima::fastrtps::rtps::RTPSReader*)#1} const&) const at MessageReceiver.cpp:717 (discriminator 2)
0x00000000007dda77: eprosima::fastrtps::rtps::MessageReceiver::process_data_message_without_security(eprosima::fastrtps::rtps::EntityId_t const&, eprosima::fastrtps::rtps::CacheChange_t&, bool) at MessageReceiver.cpp:223
Hi @lexamor,
Thanks for you effort! We'll reproduce in our end and come back to you
Is there an already existing issue for this?
Expected behavior
System should allow static discovery with reasonable amount of endpoints
Current behavior
Application crashes while endpoints static discovery for multiple participants/processes (above ~10, can depend on the system performance capabilities)
Steps to reproduce
Fast DDS version/commit
2.9.1
Platform/Architecture
Ubuntu Focal 20.04 amd64, Ubuntu Focal 20.04 arm64
Transport layer
UDPv4, Shared Memory Transport (SHM)
Additional context
It seems that some data race is happened during the static endpoints processing because of lack of the implementation of the syncronization mechanizms.
Following patch locally (completely) eliminates / fixes issue for me, but it is a bit hard to prove it completely because of debugging complexity.
Segmentation fault backtrace:
ThreadSanitizer report:
XML configuration file
No response
Relevant log output
No response
Network traffic capture
No response