Bug 436830 - Memory leak in ns-slapd's Class Of Service
Summary: Memory leak in ns-slapd's Class Of Service
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.1.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
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:
Environment:
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:
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 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.
"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 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.

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.