[Date Prev][Date Next]
Re: (ITS#4780) ACL set memory leak
On Tuesday 19 December 2006 19:39, email@example.com wrote:
> firstname.lastname@example.org wrote:
> > On Saturday 16 December 2006 08:54, email@example.com wrote:
> >> firstname.lastname@example.org 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?
Here's the valgrind output with the set clause in place:
Here's the valgrind output without the set clause (for reference):
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
+++ openldap-2.3.31/servers/slapd/sets.c 2006-12-19 21:37:40.000000000
@@ -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;
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.