michael.vishchers(a)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.
--
-- Howard Chu
CTO, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/