Log Message:
patch for ITS#3173
- passing transaction ptr to psearch
There are other issues in this code now as well. "sop" is a shared
resource, many operations may be generating psearch results
simultaneously. It was intended to be read-only, but there are now
several places in search.c that cause fields in sop to be modified. sop
now either needs to be locked, or a local copy needs to be made.
(Probably the latter is best.)
Also, all of the slap_build_XXX_ctrl functions need to use an explicit
op->o_tmpmemctx, (i.e., the tmpmemctx from the currently running
operation) not the tmpmemctx in sop. Again, since sop is shared and the
sl_mem functions assume that only one thread has access to the
tmpmemctx, this will get corrupted.
I suspect that the "locker" needs to come from the op->o_private as
well, when present; otherwise certain entrycache DB locks could deadlock.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.comhttp://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support