On Tue, 3 Apr 2012, Brice Goglin wrote:
I am fixing leaks in one of my software projects that embeds libltdl 2.4.2 to load plugins. I noticed that when the plugin depends on the dynamic library that the main program doesn't depend on, valgrind reports some leaks.
If the main program is directly linked with -lpthread do some leaks go away (or more are added)?
We created a small testcase reproducing the problem. It's available at http://www.open-mpi.org/~jsquyres/ltdl-valgrind-leaks/ Just download it, ./configure, make, make install and then run valgrind as shown below. If we remove the reference to pthread in the plugin, the leaks go away. I assume that libltdl doesn't unload these dependency libraries when the plugin is unloaded. But I'd like to know if these leaks are expected or not. The good news is that these leaks do not depend on the number of times this code is executed within the program, so the leaked size should be constant.
These reported leaks seem to be due to the glibc implementation and don't look like libltdl's fault. It is interesting to me that these reported leaks are different than I have seen before. Usually I see leaks reported for thread-specific errno and thread specific data.
It is common for glibc to secretly allocate some memory for its own use, and this is particularly true for multi-threaded programs. Often it has no way to safely release this memory.
Once you are sure that the reported issues are due to glibc (or otherwise outside of your control), you can add valgrind surpressions so that valgrind will ignore them (see valgrind documentation). Valgrind comes with its own set of surpressions but perhaps the issues you are seeing are not covered by those.
Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
