Fast-DDS
Fast-DDS copied to clipboard
memory leak with sequence in IDL struct if DataReader::take_next_sample() is called from a different thread
Is there an already existing issue for this?
- [X] I have searched the existing issues
I'm aware of the ticket https://github.com/eProsima/Fast-DDS/issues/4317 but I wasn't sure if my issue is exactly the same, since it mentions SHM transport.
Expected behavior
no memory leak
Current behavior
memory usage keeps growing
Steps to reproduce
- Create a message with sequence data type in IDL file, eg:
struct Message
{
sequence<char> data;
};
- use UDPv4 transport
- send 32k bytes in the sequence field of the message struct
- call datareader->take_next_sample() from a different thread instead of calling it in DataReaderListener::on_data_available()
- memory usage continues to grow
- move take_next_sample() into the DataReaderListener::on_data_available() callback and the memory leak goes away
I've attached a modified version of the HelloWorldExample showing the error.
Fast DDS version/commit
tested with FastDDS 2.13.2 and 2.9.1 windows 32-bit official installers. both produced the error.
Platform/Architecture
Windows 10 Visual Studio 2019
Transport layer
UDPv4, SHM
Additional context
No response
XML configuration file
<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
<transport_descriptors>
<transport_descriptor>
<transport_id>udp_transport</transport_id>
<type>UDPv4</type>
</transport_descriptor>
</transport_descriptors>
<participant profile_name="testclient">
<domainId>0</domainId>
<rtps>
<name>testclient</name>
<userTransports>
<transport_id>udp_transport</transport_id>
</userTransports>
<useBuiltinTransports>false</useBuiltinTransports>
</rtps>
</participant>
<participant profile_name="testserver">
<domainId>0</domainId>
<rtps>
<name>testserver</name>
<userTransports>
<transport_id>udp_transport</transport_id>
</userTransports>
<useBuiltinTransports>false</useBuiltinTransports>
</rtps>
</participant>
</profiles>
Relevant log output
No response
Network traffic capture
No response