RE: Memory Leak? (ITS#1488)

[hyc@highlandsun.com]

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.
>