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.
The dbgen used to generate the database : /Local/dirsrv/bin/dbgen.pl -v -o /tmp/example.ldif -n 10000
The memory leak appears only if i include the GER control into the request.
Created attachment 399443 [details] GER Memory leak test script
Created attachment 399548 [details] patch
Hi Rich, thank you, your patch works for me. The resident part of ns-slapd does not grow any more.
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)
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