[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
new memleaks in libltdl
From: |
Ralf Wildenhues |
Subject: |
new memleaks in libltdl |
Date: |
Sun, 24 Jun 2007 13:26:10 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
While reviewing Gary's 330 patch, I noticed that the patch that
introduced lt_dladvise also introduced some memleaks:
- advise_taken in tryall_dlopen is malloced several times,
unnecessarily, and not freed in each code path. AFAICS the code can
be greatly simplified by dropping advise_taken and changing the third
parameter of lt_dladvise to be of type lt__advise *. There are no
memory or ownership transfers needed here.
- there is another leak in try_dlopen which I haven't analyzed further:
==17020== 154 bytes in 3 blocks are still reachable in loss record 5 of 6
==17020== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==17020== by 0x8049831: lt__malloc (lt__alloc.c:59)
==17020== by 0x804BE42: try_dlopen (ltdl.c:1214)
==17020== by 0x804C713: lt_dlopenadvise (ltdl.c:1601)
==17020== by 0x8048E59: moduleopen (main.c:25)
==17020== by 0x804902C: hint_resident (main.c:83)
==17020== by 0x8049257: main (main.c:173)
Both are exposed by the lt_dladvise testsuite test and reproducible on
GNU/Linux with
make check-local TESTSUITEFLAGS='32 -v -d -x'
cd tests/testsuite.dir/32
LD_LIBRARY_PATH=`pwd`/.libs
valgrind --show-reachable=yes --leak-check=yes ./main
And the patch broke compilation with a C++ compiler, as Bob noted
off-list.
Cheers,
Ralf
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- new memleaks in libltdl,
Ralf Wildenhues <=