Bug 436830 - Memory leak in ns-slapd's Class Of Service
Memory leak in ns-slapd's Class Of Service
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
1.1.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Noriko Hosoi
Chandrasekar Kannan
:
Depends On:
Blocks: 249650 FDS1.2.0
  Show dependency treegraph
 
Reported: 2008-03-10 14:24 EDT by Tamas Bagyal
Modified: 2015-01-04 18:31 EST (History)
4 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 19:02:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
valgrind's output (186.17 KB, text/plain)
2008-03-10 14:25 EDT, Tamas Bagyal
no flags Details
valgrind output, run with --num-callers=40 (278.03 KB, text/plain)
2008-04-04 05:25 EDT, Tamas Bagyal
no flags Details
cos definition entrys (8.37 KB, text/plain)
2008-04-04 05:26 EDT, Tamas Bagyal
no flags Details
cos template entrys (3.41 KB, text/plain)
2008-04-04 05:27 EDT, Tamas Bagyal
no flags Details
test ldif files to reproduce the memory leak (20.00 KB, application/x-tar)
2009-01-08 16:34 EST, Noriko Hosoi
no flags Details
output (snippet) from valgrind when the previous ldif files are added by ldapmodify (3.05 KB, text/plain)
2009-01-08 16:40 EST, Noriko Hosoi
no flags Details
cvs diff ldapserver/ldap/servers/plugins/cos/cos_cache.c (1.08 KB, patch)
2009-01-08 17:08 EST, Noriko Hosoi
no flags Details | Diff
cvs commit message (698 bytes, text/plain)
2009-01-08 18:13 EST, Noriko Hosoi
no flags Details
valgrind output (9.69 KB, application/octet-stream)
2009-03-12 13:36 EDT, Jenny Galipeau
no flags Details

  None (edit)
Description Tamas Bagyal 2008-03-10 14:24:28 EDT
From Bugzilla Helper:
User-Agent: Opera/9.50 (X11; Linux i686; U; en)

Description of problem:
I found a memory leak in ns-slapd when using cos. the fds build on a debian 
etch using the build-ds script and follow the instructions on the mailing-list.
the database replicated from an fds version 1.0.4 which is in mmr with 1.1.0.
errors log shows nothing.

valgrind's output see in the attachment.

Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
nothing special. i just follow the instructions in the the thread.

Actual Results:


Expected Results:


Additional info:
Comment 1 Tamas Bagyal 2008-03-10 14:25:37 EDT
Created attachment 297486 [details]
valgrind's output
Comment 2 Rich Megginson 2008-04-03 16:44:08 EDT
I've been trying various ways to reproduce this problem, but I have not been
able to get a stack trace like this one:
==28389== 5,927,334 (4,711,269 direct, 1,216,065 indirect) bytes in 392,488
blocks are definitely lost in loss record 54 of 54
1) Can you use valgrind --num-callers=40 to print the full stack traces?
2) Can you post your Class of Service configuration?
Comment 3 Tamas Bagyal 2008-04-04 05:23:56 EDT
1) The new valgrind output is the attachment.

2) see attachments. I hope these are what you think.
Comment 4 Tamas Bagyal 2008-04-04 05:25:58 EDT
Created attachment 300399 [details]
valgrind output, run with --num-callers=40
Comment 5 Tamas Bagyal 2008-04-04 05:26:38 EDT
Created attachment 300400 [details]
cos definition entrys
Comment 6 Tamas Bagyal 2008-04-04 05:27:35 EDT
Created attachment 300401 [details]
cos template entrys
Comment 7 Rich Megginson 2008-04-04 09:55:48 EDT
This is excellent.  Thank you very much!
Comment 9 Tamas Bagyal 2008-04-09 04:18:00 EDT
I made some test and I found 2 thing:

1) this bug is present in 1.0.4 too... ( build on debian etch by ds-build 
script patched with https://www.redhat.com/archives/fedora-directory-
commits/2007-September/msg00064.html )

2) when i remove all cos definition/template entry and turned off per-subtree 
password policy, the memory usage is stay at normal level.
Comment 10 Noriko Hosoi 2009-01-08 16:34:49 EST
Created attachment 328495 [details]
test ldif files to reproduce the memory leak

How to reproduce the problem:
ldapmodify -p <port> -D 'cn=Directory Manager' -w <pw> -a -f cos-template.ldif
ldapmodify -p <port> -D 'cn=Directory Manager' -w <pw> -a -f cos-definition.ldif
ldapmodify -p <port> -D 'cn=Directory Manager' -w <pw> -a -f cos-data.ldif
ldapmodify -p <port> -D 'cn=Directory Manager' -w <pw> -a -f cos-data0.ldif
ldapmodify -p <port> -D 'cn=Directory Manager' -w <pw> -a -f cos-data1.ldif
ldapmodify -p <port> -D 'cn=Directory Manager' -w <pw> -a -f cos-data2.ldif
ldapmodify -p <port> -D 'cn=Directory Manager' -w <pw> -a -f cos-data3.ldif
Comment 11 Noriko Hosoi 2009-01-08 16:40:14 EST
Created attachment 328496 [details]
output (snippet) from valgrind when the previous ldif files are added by ldapmodify
Comment 12 Noriko Hosoi 2009-01-08 17:08:15 EST
Created attachment 328497 [details]
cvs diff ldapserver/ldap/servers/plugins/cos/cos_cache.c

Fix Description: When all the necessary values for the template cache are not available, the allocated memory should be discarded.  One of them pCosPriority was missed to release.
"cos_cache.c"
1126 static int  cos_dn_tmpl_entries_cb (Slapi_Entry* e, void *callback_data) {
    [...]
1247         else
1248         {
1249         /* 
1250         this template is brain dead - bail
1251         if we have a dn use it to report, if not then *really* bad
1252         things are going on
1253         - of course it might not be a template, so lets
1254         not tell the world unless the world wants to know,
1255         we'll make it a plugin level message
1256             */
Comment 13 Noriko Hosoi 2009-01-08 18:13:11 EST
Created attachment 328507 [details]
cvs commit message

Reviewed by Rich (Thank you!!)

Checked in into CVS HEAD.
Comment 14 Jenny Galipeau 2009-03-12 13:36:37 EDT
Created attachment 334974 [details]
valgrind output
Comment 15 Jenny Galipeau 2009-03-12 13:36:59 EDT
Please see attached valgrind output while running test ldif files - looks a lot better than previous attached output.  Noriko - will this suffice?
Comment 16 Noriko Hosoi 2009-03-12 14:36:27 EDT
(In reply to comment #15)
> Please see attached valgrind output while running test ldif files - looks a lot
> better than previous attached output.  Noriko - will this suffice?  

Jenny, I wonder how you ran valgrind with the server.  Is it from you start the server with valgrind.  Ran something like the commands in comment #10 then shutdown the server?

I don't see many leak reports we usually see in your valgrind output...
Comment 17 Noriko Hosoi 2009-03-12 14:56:12 EDT
I learned how Jenny ran the server with valgrind in the email conversation.  That's the right way to do it.  I scanned her valgrind output and did not see any cos_cache related leak messages in it, thus I'm going to mark verified.
Comment 18 Chandrasekar Kannan 2009-04-29 19:02:50 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html

Note You need to log in before you can comment on or make changes to this bug.