Multiple domain participants (one root user) using SHM causes 100% CPU

[ds58]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

Creating domain participants with the following setup should result in no communication (because of memory security policies) and not use 100% CPU:

• multiple domain participants running under different users
• at least one domain participant running as root user
• default builtin transports (shared memory)

Current behavior

Creating multiple domain participants with the default builtin transports on the same machine on multiple users and at least one root user causes 100% CPU usage of a thread.

Steps to reproduce

1. Build and install Fast-DDS locally
2. Compile the HelloWorldExample in fastdds/examples/cpp/dds/HelloWorldExample (mkdir build, cd build, cmake .., make)
3. Run an instance of the HelloWorldExample under a non-root user (./HelloWorldExample publisher)
4. Run an instance of the HelloWorldExample under the root user (./HelloWorldExample subscriber)
5. Observe the CPU usage of the instance of HelloWorldExample running under the non-root user (in this case, the publisher)

You should notice 100% usage of a CPU thread (watch top or htop while doing this)

Disabling shared memory transport resolves the problem

Fast DDS version/commit

67ba92f
Latest master at the time of testing

Platform/Architecture

Ubuntu Focal 20.04 amd64, Other. Please specify in Additional context section.

Transport layer

Default configuration, UDPv4 & SHM, Shared Memory Transport (SHM)

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[Mario-DL]

Hi @ds58

Thanks for the report. I added a clarification in the documentation regarding the usage of SHM and processes launched with different privileges.

[jespersmith]

While requiring the same user is reasonable, I do think that the participants should warn and fail gracefully instead of using 100% CPU.

[calvertdw]

I agree. Fast-DDS should not ever free spin at 100% CPU in this case, but throw a big error message. This bug can cripple users for a long time and took us countless engineering hours to A) notice the CPU usage and B) find the source of the issue.

The documentation added doesn't describe the symptoms either, which is what users might search for.