Jump to content
OpenSplice DDS Forum
luca.gherardi

Memcheck with Valgrind

Recommended Posts

Hi all,

 

I found other posts on this topic but I didn't find detailed answers about the problem.

 

I'm implementing a simple application to evaluate open splice. I tried to ran it with valgrind to check if I have memory leaks.

Valgrind (with the option leak-check==full) found white a lot of errors, so I decided to test one of the examples provided with the binaries.

 

Attached you can find the output of valgrind (both with and without the leak-check==full option) for the publisher of the Hello World example (cpp, standalone).

 

Just as a quick summary these are the two main problems:

- Few errors of type: Syscall param sendmsg(msg.msg_iov[2]) points to uninitialised byte(s)

- A lot of lost bytes

 

This is the leak summary obtained with the leak-check==full option

 

==5758== LEAK SUMMARY:
==5758==    definitely lost: 2,823 bytes in 63 blocks
==5758==    indirectly lost: 38,242 bytes in 1,427 blocks
==5758==      possibly lost: 856,354 bytes in 13,216 blocks
==5758==    still reachable: 1,523,814 bytes in 1,180 blocks
==5758==         suppressed: 0 bytes in 0 blocks
==5758== Reachable blocks (those to which a pointer was found) are not shown.
==5758== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5758== 
==5758== For counts of detected and suppressed errors, rerun with: -v
==5758== Use --track-origins=yes to see where uninitialised values come from
==5758== ERROR SUMMARY: 10285 errors from 10277 contexts (suppressed: 0 from 0)

I would like to better understand if these leaks are known and why they are happening. 

 

Some notes on my setup:

  • I'm using open splice community edition (I downloaded the binaries), under Ubuntu 12.04.

    I'm using the default configuration file (ospl.xml)

  • I'm using the single process deployment
  • In my application I configured the durability to be volatile, butI still have the memory leaks.
  • It seems to me that the number of bytes in use at exit varies form one execution to another. 
  • If I just create a participant and delete at before closing the process, there are already leaks and syscall errors

 

Please let me know if you need additional information.

 

Thanks,

Luca

Archive.zip

Share this post


Link to post
Share on other sites

we're aware of this allocated memory not being freed by application-actions .. its an 'artefact' of our 'evolution' from federated-deployment (where a single-copy of any information is managed in a shared-memory-segment i.e. independent of the number of applications ) towards the simplified 'single-process' deployment where there are no daemons and the middleware is linked as a library with the (each) application.

 

You could distinguish between what we consider 'real' memory-leaks i.e. memory (constantly) leaking away during normal operation and memory thats pre-allocated and thats currently not being freed during the removal of the DDS-entities on application-level (which is what you're observing) and for which we let the operating take-care of returning it 'on exit' (.. and being reported as 'leaks' by valgrind). 

 

There should be NO memory leaks of the 1st category, unless your data-model and application behavior causes ever-more data (often instances) to be 'alive' in the system without RESOURCE_LIMITS being defined as QoS's ..

 

As we've gotten similar remarks before on the difficulty of interpreting valgrind results, we've changed (improved) the behavior of our recent versions .. you could perhaps try/verify that by using an eval-download of our commercially-supported version(s).

Share this post


Link to post
Share on other sites

Thanks for the explanation Hans.

That's good to know.

 

Is there a way to distinguish the first category of leaks (generated by my code) and the second one (OSPL single process related)?

 

Thanks again,
Luca

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×