Date: Fri, 03 Mar 2000 16:16:44 -0500 From: Dave Hummel <dhummel@rtheory.com> To: "FreeBSD-questions@FreeBSD.ORG" <FreeBSD-questions@FreeBSD.ORG> Cc: ulmo@earthling.net Subject: Help! My treads are leaking: Openldap Message-ID: <38C02BBC.7AD9EF23@rtheory.com> References: <l03130327b4d8737ea9f8@[140.228.15.35]>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, I've hit a brick wall with getting openldap to work properly. Here's an extract from my mail to the openldap mailing list: <snip> Systems are now FreeBSD 3.4-stable, cvsup'd and compiled Feb 22, using FreeBSD uthreads. (db-2.7.7, openldap-1.2.9 both compiled from scratch (not ports) following directions/readmes found at openldap/sleepycat). Previous compile was Feb 14. I am unhappy to say the the problem has not relented even slightly. I tried two different boxes, and the result is the same. Again, configuring --without-threads causes slapd to behave properly. </snip> The problem in question is that slapd, compiled with native threads will grow with each ldap operation until all memory is exhausted. Limiting cachesize has no effect. I have no problems whatsoever when compiled without threads. I have tried FreeBSD 3.3 stable/Openldap 1.2.8 and FreeBSD 3.4 stable/Openldap 1.2.9 with the same results. I have tried the native FreeBSD db, as well as Sleepycat's latest version. I have also tried this on several boxes, all with recently cvsup'd code with a variety of compile options. I have tried building from the port, and building by hand. Every time the result is the same. It would appear that there is definitely some leakage with the thread routines. Could somebody give me a few pointers on how to track down the cause of this leakage? This is very annoying, and I know of several other people who have been struggling with this problem for a long time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38C02BBC.7AD9EF23>