Bug 572677

Summary: Memory leak in searches including GER control
Product: [Retired] 389 Reporter: Andrey Ivanov <andrey.ivanov>
Component: Security - Access Control (GER)Assignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.2.6CC: jgalipea
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 16:31:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 434914, 543590    
Attachments:
Description Flags
GER Memory leak test script
none
patch rmeggins: review+

Description Andrey Ivanov 2010-03-11 20:21:36 UTC 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)

Making several large searches with GER control shows a substantial memory leak (the resident part of the server grows fast until it reaches physical memory max)

Reproducible: Always

Steps to Reproduce:
1. Install the latest version of 1.2.6 (i have compiled from the sources, i think rpm version should not be much different)
2. Create a database with 10000 entries by dbgen.pl.
3. Use the script attached to this bugzilla report, adjusting  $bind_entry_dn to a user present in the generated ldif.
Actual Results:  
The resident memory grows rapidly from 300Mb to 4Gb or 8Gb or more (depending on the max physical memory available on the server)

Expected Results:  
The memory should not leak.
Comment 1 Andrey Ivanov 2010-03-11 20:22:53 UTC 
The dbgen used to generate the database :
/Local/dirsrv/bin/dbgen.pl -v -o /tmp/example.ldif -n 10000
Comment 2 Andrey Ivanov 2010-03-11 20:24:00 UTC 
The memory leak appears only if i include the GER control into the request.
Comment 3 Andrey Ivanov 2010-03-11 20:25:06 UTC 
Created attachment 399443 [details]
GER Memory leak test script
Comment 4 Rich Megginson 2010-03-12 03:55:27 UTC 
Created attachment 399548 [details]
patch
Comment 5 Andrey Ivanov 2010-03-12 07:53:58 UTC 
Hi Rich,

thank you, your patch works for me. The resident part of ns-slapd does not grow any more.
Comment 6 Rich Megginson 2010-03-12 15:41:57 UTC 
To ssh://git.fedorahosted.org/git/389/ds.git
   2b39f92..ed46340  master -> master

commit ed463407ead1f63ba26f64740a1e5cd1d79a03ee
Author: Rich Megginson <rmeggins>
Date:   Thu Mar 11 20:54:42 2010 -0700
    Reviewed by: Andrey Ivanov (Thanks!)
    Branch: HEAD
    Fix Description: The per-operation acl pblocks are cached.  In order to
    release the pblock back to the cache free list, the connection must be
    provided.  The connection comes from the pblock.
    Platforms tested: RHEL5 x86_64
    Flag Day: no
    Doc impact: no

To ssh://git.fedorahosted.org/git/389/ds.git
   dd7054c..87d2477  Directory_Server_8_2_Branch -> Directory_Server_8_2_Branch
commit 87d2477da35f4a029a225dd37917d4405d94ba54
Author: Rich Megginson <rmeggins>
Date:   Thu Mar 11 20:54:42 2010 -0700
    Reviewed by: Andrey Ivanov (Thanks!)
    Branch: Directory_Server_8_2_Branch
    Fix Description: The per-operation acl pblocks are cached.  In order to
    release the pblock back to the cache free list, the connection must be
    provided.  The connection comes from the pblock.
    Platforms tested: RHEL5 x86_64
    Flag Day: no
    Doc impact: no
    (cherry picked from commit ed463407ead1f63ba26f64740a1e5cd1d79a03ee)
Comment 7 Jenny Severance 2010-06-04 20:23:14 UTC 
verified - RHEL 4

version:
redhat-ds-base-8.2.0-2010060404.el4dsrv

1. generated ldif file and imported
dbgen.pl  -o example.ldif -n 10000

2. modified attached test script and ran several times while watching memory usage

3. No memory spikes or growth