One program is initialized and deinitialized repeatedly by the other program, handle leak

[vinaxixi]

Is there an already existing issue for this?

• [X] I have searched the existing issues

Expected behavior

The handle count of the program keep same before initialized and after deinitialized.

Current behavior

The handle count increases before initialized and after deinitialized. I can see many handles named like BaseNamedObjects\boost.ipcXXXXXXXXXX by processHacker.exe.

Steps to reproduce

Environment: Windows

1. There are two programs, program A use grpc to call program B's functions: Initialized and Deinitialized;
2. Functions as follows: Program B Initialized: create two participants and two subscribers; Deinitialized: destroy subscribers and participants;program B ;

Steps:

1. Programs A create one participant and one subscriber, then call program B's Initialized, after 10 seconds, A call B's Deinitialized, then A destroy subscriber and participant and exit, B still run;
2. Check program B's handle count by ProcessHacker.exe, assume is nFirst;
3. Restart program A and repeate step one and step two, the handle count of program B increases, and I can see many handles named like BaseNamedObjects\boost.ipcXXXXXXXXXX by processHacker.exe.

Fast DDS version/commit

FastDDS version 2.6.0

Platform/Architecture

Windows 10 Visual Studio 2019

Transport layer

Shared Memory Transport (SHM)

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[vinaxixi]

If I use udp, handle does not leak, but if i use shm, it will leak.

[JLBuenoLopez]

Thanks for the report @vinaxixi,

Shared Memory Transport depends on Boost which is initialized as a singleton, so even if you deinitialized, some resources are going to be kept until the process is closed.

[vinaxixi]

Thanks for you reply @JLBuenoLopez-eProsima . But handle will increases each time when i repeated step one. If we think boost is Singleton, handle count shoule not change after the first operation, and the count should be same when repeat the operation for the second time and third time.

[vinaxixi]

And i want to know, whether there is an upper limit on the handle count in dds or boost? If not, this will lead to program crash after many many repeated operations, right? Thank you very much.

[vinaxixi]

@JLBuenoLopez-eProsima I think it's should not be labeled "invalid". That's not the problem, maybe here: RTPSParticipantImpl.cpp -> RTPSParticipantImpl constructor -> createReceiverResources, some boost.ipcXXXXXXXXXX mutant handle appear when i run here. Can you have a try?

[vinaxixi]

@JLBuenoLopez-eProsima I think it should not be labeled "invalid". That's not the problem, maybe here: RTPSParticipantImpl.cpp -> RTPSParticipantImpl constructor -> createReceiverResources, some boost.ipcXXXXXXXXXX mutant handle appear when i run here. Can you have a try?

[Mario-DL]

Hi @vinaxixi,

Fast DDS v2.6.6 release fixed some issues with shared memory segment management. Could you please test with Fast DDS v2.6.9 ?

[Mario-DL]

According to our CONTRIBUTING.md guidelines, I am closing this issue due to inactivity. Please, feel free to reopen it if necessary.