Memory leak when constantly registering and unregistering instances (c++11)

2 posts / 0 new
Last post
Last seen: 2 years 11 months ago
Joined: 09/17/2015
Posts: 53
Memory leak when constantly registering and unregistering instances (c++11)

Hello all, 

We have our own RPC system which does the following when a request in form of some dds sample on an unrelated topic arrives:

  1. Create response sample
  2. Register sample and store instance handle 
  3. Write sample
  4. Dispose instance by using the handle
  5. Unregister instance by using the handle.

QOS is Volatile and Reliable. If we do not unregister the instances it leaks much faster, but this is of course expected. But the application as it is now should not leak.

What we tried so far:

  • Changing the keys so that no new instances are created. This fixes the leaks but this, of course, alters the applications behaviour in an undesired way. But this shows that it has something to do with instances not beeing cleaned up.
  • Setting autopurge_unregistered_instances_delay to 30 seconds. This didn't improve anything.

What else can be done? Is perhaps the datareader leaking? Do I have to unregister the instances on the reader as well?

Some valgrind output:

==11765==    at 0x4C2AD10: calloc (vg_replace_malloc.c:623)
==11765==    by 0x9746573: RTIOsapiHeap_reallocateMemoryInternal (in /opt/rti_connext_dds-5.2.0/lib/x64Linux3.xgcc4.6.3/
==11765==    by 0x9728B53: REDAFastBufferPool_growEmptyPoolEA (in /opt/rti_connext_dds-5.2.0/lib/x64Linux3.xgcc4.6.3/
==11765==    by 0x97294E2: REDAFastBufferPool_newWithNotification (in /opt/rti_connext_dds-5.2.0/lib/x64Linux3.xgcc4.6.3/
==11765==    by 0x97295E3: REDAFastBufferPool_new (in /opt/rti_connext_dds-5.2.0/lib/x64Linux3.xgcc4.6.3/
==11765==    by 0x9528338: PRESPsService_new (in /opt/rti_connext_dds-5.2.0/lib/x64Linux3.xgcc4.6.3/
==11765==    by 0x8E161FE: DDS_DomainParticipantService_initialize (in /opt/rti_connext_dds-5.2.0/lib/x64Linux3.xgcc4.6.3/
==11765==    by 0x8DF9F4C: DDS_DomainParticipant_createI (in /opt/rti_connext_dds-5.2.0/lib/x64Linux3.xgcc4.6.3/
==11765==    by 0x8DD91C4: DDS_DomainParticipantFactory_create_participant_disabledI (in /opt/rti_connext_dds-5.2.0/lib/x64Linux3.xgcc4.6.3/
==11765==    by 0x86D031E: rti::domain::detail::create_native_participant(unsigned int, dds::core::TEntityQos<rti::domain::qos::DomainParticipantQosImpl> const*, dds::domain::DomainParticipantListener*, dds::core::status::StatusMask const&) (in /opt/rti_connext_dds-5.2.0/lib/x64Linux3.xgcc4.6.3/
==11765==    by 0x86D0585: rti::domain::DomainParticipantImpl::DomainParticipantImpl(unsigned int, dds::core::TEntityQos<rti::domain::qos::DomainParticipantQosImpl> const&, dds::domain::DomainParticipantListener*, dds::core::status::StatusMask const&) (in /opt/rti_connext_dds-5.2.0/lib/x64Linux3.xgcc4.6.3/
==11765==    by 0x86D5190: rti::domain::FactoryPluginSupport::create_participant(int, DDS_DomainParticipantQos const*, void*, unsigned int) (in /opt/rti_connext_dds-5.2.0/lib/x64Linux3.xgcc4.6.3/
Last seen: 6 days 22 hours ago
Joined: 04/02/2013
Posts: 145


The call stack you copied suggests that the DomainParticipant is not being deleted and seems unrelated to the DataReader. Can you increase the call stack (e.g. --num-callers=30) to get more context?

Can you share a simple application that exhibits this leak so we can debug it?