[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Memory Leak? (ITS#1488)
Howard,
I am using BDB version 3.2.9, and the ldap database is ~37Mb plus indexes
of ~6Mb (we are indexing 7 fields).
We are using libnss-ldap, and are running versions of apache, proftpd,
solid-pop3d and imapd that authenticate against ldap (either directly or
using libpam-ldap). There are no connections being held open to the ldap
server without being closed properly, but as you can imagine the ldap
server can get quite busy. All connections come from localhost, except for
updates, which come from a central server which replicates to the servers
that appear to have the leak.
On another note, we are also running the same copy of slapd on the central
ldap server, which does not appear to have the same problem (it is
currently a ~12Mb process after running for over 3 weeks). The main
difference is that the central server will only ever have 1 or 2 programs
performing ldap requests at a time (although many of these requests involve
reading the entire ldap tree, as part of a synchronization process).
I am having problems compiling the FunctionCheck library, but am very
interested to get it working. The configure/make output follows.
thanks
Steven
# CC=gcc-3.0 ./configure
loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... (cached) gcc-3.0
checking whether the C compiler (gcc-3.0 ) works... yes
checking whether the C compiler (gcc-3.0 ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc-3.0 accepts -g... (cached) yes
checking for c++... (cached) c++
checking whether the C++ compiler (c++ ) works... yes
checking whether the C++ compiler (c++ ) is a cross-compiler... no
checking whether we are using GNU C++... (cached) yes
checking whether c++ accepts -g... (cached) yes
checking for a BSD compatible install... /usr/bin/install -c
checking whether make sets ${MAKE}... (cached) yes
checking host system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for ranlib... (cached) ranlib
checking for ld used by GCC... (cached) /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes
checking for BSD-compatible nm... (cached) /usr/bin/nm -B
checking whether ln -s works... (cached) yes
loading cache ./config.cache within ltconfig
checking for object suffix... o
checking for executable suffix... (cached) no
checking for gcc-3.0 option to produce PIC... -fPIC
checking if gcc-3.0 PIC flag -fPIC works... yes
checking if gcc-3.0 supports -c -o file.o... yes
checking if gcc-3.0 supports -c -o file.lo... yes
checking if gcc-3.0 supports -fno-rtti -fno-exceptions ... yes
checking if gcc-3.0 static flag -static works... -static
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking command to parse /usr/bin/nm -B output... ok
checking how to hardcode library paths into programs... immediate
checking for /usr/bin/ld option to reload object files... -r
checking dynamic linker characteristics... Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for objdir... .libs
creating libtool
loading cache ./config.cache
checking for dlopen in -ldl... (cached) yes
checking for objalloc_create in -liberty... (cached) no
checking for bfd_open_file in -lbfd... (cached) no
checking for cos in -lm... (cached) yes
checking how to run the C preprocessor... (cached) gcc-3.0 -E
checking for ANSI C header files... (cached) yes
checking for bfd.h... (cached) no
checking for sys/time.h... (cached) yes
checking for unistd.h... (cached) yes
checking for working const... (cached) yes
checking for pid_t... (cached) yes
checking for size_t... (cached) yes
checking whether time.h and sys/time.h may both be included... (cached) yes
checking return type of signal handlers... (cached) void
checking for gettimeofday... (cached) yes
checking for strdup... (cached) yes
creating ./config.status
creating doc/Makefile
creating test/Makefile
creating src/Makefile
creating src/include/Makefile
creating src/lib/Makefile
creating src/dump/Makefile
creating Makefile
# make
Making all in src
make[1]: Entering directory `/usr/local/src/fnccheck-1.4.hyc/src'
Making all in include
make[2]: Entering directory `/usr/local/src/fnccheck-1.4.hyc/src/include'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/local/src/fnccheck-1.4.hyc/src/include'
Making all in lib
make[2]: Entering directory `/usr/local/src/fnccheck-1.4.hyc/src/lib'
/bin/sh ../../libtool --mode=compile gcc-3.0 -DPACKAGE=\"fnccheck\"
-DVERSION=\"1.4\" -DHAVE_LIBDL=1 -DHAVE_LIBM=1 -DSTDC_HEADERS=1
-DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DTIME_WITH_SYS_TIME=1
-DRETSIGTYPE=void -DHAVE_GETTIMEOFDAY=1 -DHAVE_STRDUP=1 -I. -I. -g
-O2 -c fncmalloc.c
rm -f .libs/fncmalloc.lo
gcc-3.0 -DPACKAGE=\"fnccheck\" -DVERSION=\"1.4\" -DHAVE_LIBDL=1
-DHAVE_LIBM=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1
-DTIME_WITH_SYS_TIME=1 -DRETSIGTYPE=void -DHAVE_GETTIMEOFDAY=1
-DHAVE_STRDUP=1 -I. -I. -g -O2 -Wp,-MD,.deps/fncmalloc.pp -c -fPIC -DPIC
fncmalloc.c -o .libs/fncmalloc.lo
fncmalloc.c:16: conflicting types for `__malloc_hook'
/usr/include/malloc.h:226: previous declaration of `__malloc_hook'
fncmalloc.c:17: conflicting types for `__realloc_hook'
/usr/include/malloc.h:229: previous declaration of `__realloc_hook'
fncmalloc.c:18: conflicting types for `__free_hook'
/usr/include/malloc.h:224: previous declaration of `__free_hook'
make[2]: *** [fncmalloc.lo] Error 1
make[2]: Leaving directory `/usr/local/src/fnccheck-1.4.hyc/src/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/fnccheck-1.4.hyc/src'
make: *** [all-recursive] Error 1
At 09:54 PM 10/12/01 -0800, Howard Chu wrote:
>I've re-read ITS #1463. If you want the matter investigated, it will help to
>also know which version of BDB you are using. (I presume you are using BDB
>from your log file but I have no idea.) Also some idea of the size of your
>database and the nature of the LDAP requests.
>
>Another idea, which can be very illuminating, but requires GCC >= 2.95.2:
>there is a package called FunctionCheck which is not only a code profiler
>(ala gprof) but can also trace malloc activity. You must compile all of your
>code with the gcc 3 option "-finstrument-functions" and link with the
>FunctionCheck library to use the package. Running with this package will
>absolutely identify the source of the memory leaks. If you decide to try
>this route, I also suggest you use the version that I have put up on
>www.freshmeat.net at http://freshmeat.net/branches/18496/
>
>The original 1.4 release was extremely slow and would take hours to process
>the slapd symbol table. My version has optimized the symbol lookups so that
>it is possible to analyze a trace from slapd in only a few seconds.
>
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support
>
> > -----Original Message-----
> > From: owner-openldap-bugs@OpenLDAP.org
> > [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of
> > steven.wilton@team.eftel.com
>
> > Full_Name: Steven Wilton
> > Version: 2.0.18
> > OS: Linux
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (203.24.100.132)
> >
> >
> > Look at ITS#1463 for initial report (which was closed).
> >
> > Futher information:
> >
> > If I force a coredump (kill -11), the resulting file is ~95% NULL
> > characters (of
> > a 160Mb file), so it does not look like the cache filling up, or
> > if it is, there
> > is a problem with the cache code.
> >