[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libltdl leaks when unloading plugins depending on external lib
From: |
Bob Friesenhahn |
Subject: |
Re: libltdl leaks when unloading plugins depending on external lib |
Date: |
Tue, 3 Apr 2012 16:13:17 -0500 (CDT) |
User-agent: |
Alpine 2.01 (GSO 1266 2009-07-14) |
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
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/