Question

My application processes thousands of messages and uses dlopen / dlclose etc to call functions in shared libraries at runtime.

I have been analysing the memory at runtime and it seems (as I expected) that dlclose() does not free any malloc’ed memory after the close. So I have a rather bad memory leak….

The problem is these shared libs were written by someone else and I am not allowed to change the source. Is there any way around this? I suppose I could call a “subprocess” to process the message and then when it terminates the memory will dissappear for that subprocess….

Any other ideas?

Thanks for the help

Lynton

Answer 1

It’s not clear from your question whether the memory “leaked” is memory allocated by the library you loaded, or by the dlopen implementation as part of managing the loaded libraries.

If it’s allocated by the library, then either you are misusing the library and failing to call the right functions to instruct it to free memory it allocated, or it is poorly written and allocating (perhaps on first usage) data which it plans to keep around, reuse, and never free.

If it’s allocated by the implementation of dlopen, then there’s nothing wrong; this just means dlopen decided it can’t safely unload the library, perhaps because there are still some references to its symbols hanging around. This is no problem since future loads of the same library will not consume more memory but will reuse the already-loaded copy.

Now, assuming the problem is not that you’re misusing the library, all issues should be fixable simply by keeping the library open and not calling dlclose, and reusing it yourself if/when you need it next. That way, even if the library allocated memory behind your back and offers no way to free it, this will happen only once (the first time you load the library), not “N times”, and thus it is not a “memory leak”.