Would "still reachable" VALGRIND memory leaks (Linux) relate to PRSTAT memory growth on SOLARIS?

Question

I am using Valgrind to check for leaks in a C application I have written.

I am using 3rd party libraries...but am not 100% sure if the problem really lies in them only. If I run 10 message through my code I get the following on Linux:

==12460== LEAK SUMMARY:
==12460==    definitely lost: 70,794 bytes in 11 blocks
==12460==    indirectly lost: 0 bytes in 0 blocks
==12460==      possibly lost: 69,960 bytes in 19 blocks
==12460==    still reachable: 52,095 bytes in 33 blocks
==12460==         suppressed: 0 bytes in 0 blocks

If I run 100 messages through my code I get:

==12811== LEAK SUMMARY:
==12811==    definitely lost: 70,794 bytes in 11 blocks
==12811==    indirectly lost: 0 bytes in 0 blocks
==12811==      possibly lost: 69,960 bytes in 19 blocks
==12811==    still reachable: 61,795 bytes in 133 blocks
==12811==         suppressed: 0 bytes in 0 blocks

So you can see the "still reachable" is the only one really growing here...would that relate to the fact that when I take this code to Solaris I see the SIZE field under PRSTAT grow after awhile? I would assume "still reachable" is still "kind of a memory leak"?

An example of a "still reachable" in my Valgrind log would be something like:

==12811== 848 bytes in 1 blocks are still reachable in loss record 34 of 48
==12811==    at 0x4A067BA: malloc (vg_replace_malloc.c:263)
==12811==    by 0x656F1A7: xppInitialize (in /opt/mqm/lib64/libmqmcs.so)
==12811==    by 0x6538802: InitProcessInitialisation (in /opt/mqm/lib64/libmqmcs.so)
==12811==    by 0x653A3D4: xcsInitializeEx (in /opt/mqm/lib64/libmqmcs.so)
==12811==    by 0x653AF94: xcsInitialize (in /opt/mqm/lib64/libmqmcs.so)
==12811==    by 0x6250BAC: zstMQCONNX (in /opt/mqm/lib64/libmqz.so)
==12811==    by 0x60B1605: MQCONNX (in /opt/mqm/lib64/libmqm.so)
==12811==    by 0x585CEBA: wmq_receiver_initialize (wmq_receiver.c:18)
==12811==    by 0x4E10D58: wmq_receiver_proxy_initialize (wmq_receiver_proxy.c:17)
==12811==    by 0x402D02: initialiseWMQReceiverProxy (test_outbound.c:296)
==12811==    by 0x4027E8: outboundThreadMainLoop (test_outbound.c:209)
==12811==    by 0x37EA2077E0: start_thread (in /lib64/libpthread-2.12.so)

But the above is in a 3rd party IBM library? But I cannot belive that IBM (for Websphere MQ) would have leaks in thier lib as it has been used for years and years...could I be missing something here?

Any way to better track down and fix these "still reachable" leaks? I assume I am correct in saying that this could well be the reason why I see gradual memory growth on Solaris after porting the application...

Thanks for the help ;-)

Lynton

Answer 1

"still reachable" usually means that the code has some static (or thread local) pointer variable that is initialized with malloc & Co. That this part is growing in a third party library may be an indication that this library does scale its buffers from time to time to cope with growing requests. But since there seems to be no additional "definitively lost" it seems to do this nicely, e.g by using realloc.

In your case you'd have to look if this increases much further when you stress the library. At the end you could write a "supression" file for that library, so valgrind would ignore these. On modern linux distributions you already have that for some of the standard libraries, e.g.

To my personal taste, the definitively and possibly lost parts would worry me more, and I'd clean them up first. You can only be sure that there is no leak at all if valgrind manages to capture a free for every malloc of your application.

Answer 2

"still reachable" means that there are valid pointers to those allocated blocks somewhere in the code. So it is not a traditional leak - the memory could theoretically still be freed. You are correct that this will be accounted in prstat in the SIZE metric.

Run your app for longer, with more messages. If it stabilizes, it's most likely ok - the library could build up caches (memory pools, networking buffers) to help performance for example.