Bug 436830 - Memory leak in ns-slapd's Class Of Service
Summary: Memory leak in ns-slapd's Class Of Service
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.1.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Chandrasekar Kannan
Depends On:
Blocks: 249650 FDS1.2.0
TreeView+ depends on / blocked
Reported: 2008-03-10 18:24 UTC by Tamas Bagyal
Modified: 2015-01-04 23:31 UTC (History)
4 users (show)

Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-04-29 23:02:50 UTC

Attachments (Terms of Use)
valgrind's output (186.17 KB, text/plain)
2008-03-10 18:25 UTC, Tamas Bagyal
no flags Details
valgrind output, run with --num-callers=40 (278.03 KB, text/plain)
2008-04-04 09:25 UTC, Tamas Bagyal
no flags Details
cos definition entrys (8.37 KB, text/plain)
2008-04-04 09:26 UTC, Tamas Bagyal
no flags Details
cos template entrys (3.41 KB, text/plain)
2008-04-04 09:27 UTC, Tamas Bagyal
no flags Details
test ldif files to reproduce the memory leak (20.00 KB, application/x-tar)
2009-01-08 21:34 UTC, 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 21:40 UTC, Noriko Hosoi
no flags Details
cvs diff ldapserver/ldap/servers/plugins/cos/cos_cache.c (1.08 KB, patch)
2009-01-08 22:08 UTC, Noriko Hosoi
no flags Details | Diff
cvs commit message (698 bytes, text/plain)
2009-01-08 23:13 UTC, Noriko Hosoi
no flags Details
valgrind output (9.69 KB, application/octet-stream)
2009-03-12 17:36 UTC, Jenny Severance
no flags Details

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.


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