We have several serious memory issues, like 1. Doing multiple LDAP searches in the same run uses up a lot of memory. We should see if closing/reopening the connection helps, but I doubt it. 2. When searching/retrieving lots of entries, the memory usage goes up dramatically. This might be solved by asynchronous LDAP? One user reports: Hi Leif, Thanx for the reply. Do you think if it would help if we open and close the LDAP connections more often (instead of just one connection for 900K searches), or the memory leaks can only be be stopped when perl terminates. Shalese Leif Hedstrom wrote: Shalese Huang wrote: Hi Leif, This memory leak in ldapp is the only thing that's holding us off in delivering a solution to a customer (IEEE). Is there any, any workaround we can try? Have you tried PerLDAP? I believe it will have the same problems, but it might perhaps help your application. Some indications are that PerLDAP is worse though... :-(. I don't have a solution to the problem yet, it's not a memory leak per se, there are two or three possible problems: 1.Large synchronous searches will take a lot memory. This will be addressed if/when we rewrite it to use asynchronous LDAP calls in PerLDAP. 2.There are known memory leaks in the LDAP C SDK. Make sure you get the latest, greatest v3.1 bits from DevEdge. 3.There are potentially lost reference counts in the C API for PerLDAP (and the old Ldapp). Or, possibly somehow it's missing some memory freeing, but I'm not sure how, tools like Purify do not detect them as memory leaks (since Perl still has a reference to the memory). Sorry. -- leif -- Shalese Huang Netscape Communications 650-937-4737

Setting all current Open Critical and Major to M3

Clearing "M" field since Directory product is not used for 5.0 specific project bug metrics and will mess up our queries on milestones.

This is at least partially fixed as of PerLDAP v1.2.1. I added the DESTROY method to Entry.pm, which helps a lot. I'm keeping this bug open, since there seems to be a few more (minor) leaks in the code (not sure where).

This is mostly fixed, mostly. v1.2.2 and later should work much better.