libtool-patches
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]