Le 04/04/2012 00:04, Bob Friesenhahn a écrit :
> On Tue, 3 Apr 2012, Brice Goglin wrote:
>>> 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.
>>
>> I tried
On Tue, 3 Apr 2012, Brice Goglin wrote:
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.
I tried with another dependency (libpci instead of libpthread), the
lea
Le 03/04/2012 23:13, Bob Friesenhahn a écrit :
> 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, val
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 directl
Hello,
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.
We created a small testcase reproducing the problem. It's availabl
