On Tuesday 19 December 2006 19:39, hyc@symas.com wrote:
dhawes@vt.edu wrote:
On Saturday 16 December 2006 08:54, ando@sys-net.it wrote:
dhawes@vt.edu wrote:
I notice the same behavior on 2.3.27, but did not notice it with older versions such as 2.2.26.
I can't confirm this issue neither with HEAD nor with re23; I used valgrind and the set string you posted verbatim, although I didn't use slamd. However, right now I don't see how it may be a matter of concurrency.
I notice the same behavior with 2.3.31 as well. From my testing 2.2.30 does not exhibit this behavior while 2.3.4 (and later) does.
I've also been unable to reproduce this. Can you run using valgrind or some other malloc tracer and get some diagnostics?
Absolutely.
Here's the valgrind output with the set clause in place:
http://filebox.vt.edu/users/dhawes/valgrind-with-set.log
Here's the valgrind output without the set clause (for reference):
http://filebox.vt.edu/users/dhawes/valgrind-without-set.log
The following patch causes memory use to stabilize with my SLAMD test:
--- openldap-2.3.31-orig/servers/slapd/sets.c 2006-01-03 17:16:15.000000000 -0500 +++ openldap-2.3.31/servers/slapd/sets.c 2006-12-19 21:37:40.000000000 -0500 @@ -440,6 +440,7 @@ AC_MEMCPY( set->bv_val, &filter[ - len - 1 ], len ); set->bv_len = len; SF_PUSH( set ); + cp->set_op->o_tmpfree( set->bv_val, cp->set_op->o_tmpmemctx ); set = NULL; break;
Of course, this patch makes sets useless, so it's hardly a fix. I'm still looking at the code to determine what's going on here--I'm sure you guys will be able to pinpoint it in an instant.
dave