> On 26 Apr 2019, at 01:45, Mark Reynolds <mreynolds@xxxxxxxxxx> wrote:
>
>
> On 4/25/19 11:10 AM, Ludwig wrote:
>> Hi,
>>
>>
>> when running ASAN builds I noticed in some tests a memory leak for dblayer perf counters.
>>
>> A closer look showd it happens with an online restore, in this case we have started dblayer in normal mode, then close it, but pass a mode to prevent the cleanup of the perfcounters (this is according to a comment intentionally), then we do the restore which will not touch the perf counters and then start the dblayer again, in normal mode, which just allocates new memory for the perf counters and overwrites the existing ones, which will now be leaked.
>>
>>
>> So how to deal with it:
>>
>> 1] make behaviour as intended by the comment and fix it like:
>>
>> diff --git a/ldap/servers/slapd/back-ldbm/perfctrs.c b/ldap/servers/slapd/back-ldbm/perfctrs.c
>> index 57a8cbc84..c264a7eec 100644
>> --- a/ldap/servers/slapd/back-ldbm/perfctrs.c
>> +++ b/ldap/servers/slapd/back-ldbm/perfctrs.c
>> @@ -34,7 +34,10 @@ perfctrs_init(struct ldbminfo *li __attribute__((unused)), perfctrs_private **re
>> {
>> perfctrs_private *priv = NULL;
>>
>> - *ret_priv = NULL;
>> + if(*ret_priv != NULL) {
>> + /* we already have allocated perf counters, continue to use them */
>> + return;
>> + }
>>
>> /*
>> * We need the perfctrs_private area on all platforms.
>>
>>
>> or 2]
>>
>> keep the behaviour as it is now and cleanup the perf counters if closed before RESTORE ?
>
>
> I like option 1, less freeing and allocating…
I see no issue with option 1, unless there is a need to reset the perf counters after a restore ….
>
>>
>>
>> Regards,
>>
>> Ludwig
>> _______________________________________________
>> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> _______________________________________________
> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
