Bug 440474 - memberOf: Various member operations leak memory
memberOf: Various member operations leak memory
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Server - memberOf Plug-in (Show other bugs)
1.1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Chandrasekar Kannan
:
Depends On:
Blocks: 249650 429034 FDS1.2.0
  Show dependency treegraph
 
Reported: 2008-04-03 13:55 EDT by Nathan Kinder
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:03:33 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 leak reports (8.93 KB, text/plain)
2008-04-03 13:55 EDT, Nathan Kinder
no flags Details
CVS Diffs (3.07 KB, patch)
2008-04-03 14:13 EDT, Nathan Kinder
no flags Details | Diff
valgrind output from bug verification (40.09 KB, application/x-bzip)
2009-04-02 13:43 EDT, Jenny Galipeau
no flags Details

  None (edit)
Description Nathan Kinder 2008-04-03 13:55:55 EDT
A number of memory leaks in the memberOf plug-in occur during various operations
on member attributes.  These leaks were discovered using valgrind to run
ns-slapd.  The options to valgrind used on my system were:

  valgrind --leak-check=full ./ns-slapd -D /opt/dirsrv/etc/dirsrv/slapd-windsor
-i /opt/dirsrv/var/run/dirsrv/slapd-windsor.pid -w
/opt/dirsrv/var/run/dirsrv/slapd-windsor.startpid -d 0

I will add an attachment to this bug with details on what leaks are reported by
valgrind when certain operations are performed.
Comment 1 Nathan Kinder 2008-04-03 13:55:55 EDT
Created attachment 300292 [details]
Valgrind leak reports
Comment 2 Nathan Kinder 2008-04-03 14:13:22 EDT
Created attachment 300297 [details]
CVS Diffs

These diffs address the memory leaks reported in the previous attachment.

We were allocating a Slapi_Mods in the modify callback and never calling
slapi_mods_free() at the end of the callback.  Simply added a call to
slapi_mods_free() would cause a double free. This is because we are initialing
the Slapi_Mods by passing in the LDAPMod array from SLAPI_MODIFY_MODS in the
pblock.  This will make slapi_mods_free() do a free of the LDAPMod elements,
but do_modify() is responsible for freeing the LDAPMod array in the pblock. 
The solution is to initialize the Slapi_Mods by reference so slapi_mods_free()
doesn't try to free the LDAPMod array.

There were 4 places where we were allocating a Slapi_Entry by calling
slapi_search_internal_get_entry(), but never freeing the entry when we were
finished with it.

We were allocating two Slapi_Value arrays with slapi_ch_malloc(), but were
never calling slapi_ch_free() when we were finished.
Comment 3 Nathan Kinder 2008-04-03 19:04:30 EDT
Checked into ldapserver (HEAD).

Checking in memberof.c;
/cvs/dirsec/ldapserver/ldap/servers/plugins/memberof/memberof.c,v  <--  memberof.c
new revision: 1.6; previous revision: 1.5
done
Comment 4 Jenny Galipeau 2009-04-02 13:42:54 EDT
fix verifed RHEL 5 DS 8.1
Ran all test in valgrind leaks report attachment

Attaching valgrind output from varification.
Comment 5 Jenny Galipeau 2009-04-02 13:43:43 EDT
Created attachment 337859 [details]
valgrind output from bug verification
Comment 6 Chandrasekar Kannan 2009-04-29 19:03:33 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.