[Date Prev][Date Next] [Chronological] [Thread] [Top]
RE: Memory Leak? (ITS#1488)

To: openldap-its@OpenLDAP.org
Subject: RE: Memory Leak? (ITS#1488)
From: hyc@highlandsun.com
Date: Tue, 11 Dec 2001 14:20:05 GMT
Now that I've gotten a current version of FunctionCheck running, it appears
that there are several memory leaks to close up. I will try to get a handle
on these later; it's possible that FunctionCheck is misreporting a few of
them.

  -- 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
> Sent: Monday, December 10, 2001 11:01 PM
> To: openldap-its@OpenLDAP.org
> Subject: 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.
> > >
>
Prev by Date: RE: Memory Leak? (ITS#1488)
Next by Date: some library tools/tests failing to link (ITS#1489)
Index(es):
- Chronological
- Thread