ryan(a)nardis.ca wrote: I've run your reproducer and see no memory leak. The response queue will indeed grow without bound if the consumer runs slower than the provider, and doesn't read responses fast enough. But in the case of this test script, eventually the client finishes and the consumer catches up. The provider's process size may not decrease, but that just means the malloc implementation isn't returning freed memory to the kernel - it's not a leak. This can be verified using mleak, and using SIGPROF to snapshot the memory usage of the provider. The simplest way to force the memory use to grow is to first suspend the consumer with SIGSTOP. Let the modify client run to completion. mleak / SIGPROF will show a large amount of memory in use. Resume the consumer with SIGCONT, let it run to completion, and then check with SIGPROF on the provider again - all of the response queue memory is freed. So, conclusively, there is no actual leak. But there's a problem with sustained client modifications when the consumer is too slow. Our options here are to configure a size limit on the response queue, and hang the client when the limit is hit, or to return LDAP_BUSY to the client. Neither of these are very attractive options. Doing batched commits will speed up the consumer, but that feature is only in 2.5. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/