Bug 436830

Summary: Memory leak in ns-slapd's Class Of Service
Product: [Retired] 389 Reporter: Tamas Bagyal <keef>
Component: Directory ServerAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED CURRENTRELEASE QA Contact: Chandrasekar Kannan <ckannan>
Severity: high Docs Contact:
Priority: medium    
Version: 1.1.0CC: benl, jgalipea, nhosoi, rmeggins
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: 8.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-29 23:02:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 249650, 493682    
Description Flags
valgrind's output
valgrind output, run with --num-callers=40
cos definition entrys
cos template entrys
test ldif files to reproduce the memory leak
output (snippet) from valgrind when the previous ldif files are added by ldapmodify
cvs diff ldapserver/ldap/servers/plugins/cos/cos_cache.c
cvs commit message
valgrind output none

Description Tamas Bagyal 2008-03-10 18:24:28 UTC
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:

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 18:25:37 UTC
Created attachment 297486 [details]
valgrind's output

Comment 2 Rich Megginson 2008-04-03 20:44:08 UTC
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 09:23:56 UTC
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 09:25:58 UTC
Created attachment 300399 [details]
valgrind output, run with --num-callers=40

Comment 5 Tamas Bagyal 2008-04-04 09:26:38 UTC
Created attachment 300400 [details]
cos definition entrys

Comment 6 Tamas Bagyal 2008-04-04 09:27:35 UTC
Created attachment 300401 [details]
cos template entrys

Comment 7 Rich Megginson 2008-04-04 13:55:48 UTC
This is excellent.  Thank you very much!

Comment 9 Tamas Bagyal 2008-04-09 08:18:00 UTC
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 21:34:49 UTC
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 21:40:14 UTC
Created attachment 328496 [details]
output (snippet) from valgrind when the previous ldif files are added by ldapmodify

Comment 12 Noriko Hosoi 2009-01-08 22:08:15 UTC
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.
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 23:13:11 UTC
Created attachment 328507 [details]
cvs commit message

Reviewed by Rich (Thank you!!)

Checked in into CVS HEAD.

Comment 14 Jenny Severance 2009-03-12 17:36:37 UTC
Created attachment 334974 [details]
valgrind output

Comment 15 Jenny Severance 2009-03-12 17:36:59 UTC
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 18:36:27 UTC
(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 18:56:12 UTC
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 23:02:50 UTC
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.