Crash creating a discovery server participant when built with VS2019

[VladimirVassiliev]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

Not crash.

Current behavior

Memory assess violation when calling eprosima::fastrtps::Domain::createParticipant() with discoveryProtocol set to SERVER.

The problem is the following code in PDPServer::initializeParticipantProxyData() (PDPServer.cpp):

    // Set discovery server version property
    participant_data->m_properties.push_back(
        std::pair<std::string,
        std::string>({dds::parameter_property_ds_version, dds::parameter_property_current_ds_version}));

Doing the following fixes the problem:

    // Set discovery server version property
    participant_data->m_properties.push_back(dds::parameter_property_ds_version, dds::parameter_property_current_ds_version);

The same code also exists in PDPClient.cpp.

Steps to reproduce

• Make a debug build of FastDDS 2.6.2 with VS2019
• Run fast-discovery-serverd-1.0.0.exe
• Unhandled exception at 0x00A46C8A in fast-discovery-serverd-1.0.0.exe: 0xC0000005: Access violation writing location 0xCCCCCCCC.

Fast DDS version/commit

2.6.2

Platform/Architecture

Windows 10 Visual Studio 2019

Transport layer

UDPv4

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[Mario-DL]

Hi @VladimirVassiliev,

I could not reproduce the issue with the information provided, the output I obtained was the help being printed in the console. I also tried running it with -i 0 and it correctly launches. Looking at the workaround you described, it seems to me that the issue may has to do with the compiler. What compiler version are you using ?

[VladimirVassiliev]

Hi @Mario-DL, I am sorry for late reply.
I believe I was using VS2019 version 16.11.18 or 16.11.19 at that time. I haven't tried reproducing the crash with later versions. Did you use the debug build?
The problem is definitely compiler specific, as the current code works fine with GCC. However, I am not sure if it is a compiler bug. I think it could be an undefined behaviour case. The fix I suggested makes the code simpler and works with all compilers. It is also consistent with other use cases in Fast-DDS.

[Mario-DL]

Hello @VladimirVassiliev

I double checked with FastDDS 2.6.2 in Debug mode with MVSC 2019 v142 and the issue does not occur. As the configuration of your compiler is unknown i will move this conversation to the corresponding forum according to our CONTRIBUTING.md guidelines. Nonetheless, we thank you for the proposed fix and we are aware in case it happens in the future.