michael.vishchers@7p-group.com wrote:

--_004_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_ Content-Type: multipart/alternative; boundary="_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_"

--_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It is not the client loop that is multithreading but the ldap server.

Thanks for clarifying.

And it is not a misuse of the API but a problem that may be raised by day t= o day network problems.

I've boiled down the problem to a few simple configurations that work (or b= etter, fail ;-) with both 2.4.23 and 2.4.36. A tgz file containing a setup = with start script and testclient is attached. It should be sufficient to re= produce the fault.

The problem occurs only if we use session variable substitution in the rwm = overlay, and only if a search is *immediately* (e.g. caused by network loss= and client timeout) followed by an unbind.

Yes, your test config shows that the problem is that rwm_conn_destroy frees the session context while rwm_op_search is using it. Seems like the rwm overlay is not doing reference counting properly.