[Fedora-directory-devel] Re: memberOf plug-in memory leaks and bugs, proposals of patch

Nathan Kinder nkinder at redhat.com
Mon Mar 24 16:09:17 UTC 2008


Andrey Ivanov wrote:
> Hi,
>
> I have tried to adapt  the memberOf plugin as it exists in today in
> the CVS to our production environment - it is a very nice and USEFUL
> addition to server features, especially if one has to manage direct
> and indirect groups.
>
> We have several relatively large groups (~ 3000 entries). It turned
> out that at each full group members delete and recreation I've had
> huge memory leaks (~ 100 Mb per each full delete/recreation). I've
> tried to narrow it down in the plug-in. here is what i have found (i
> structured it in paragraphs) :
>
> §1.There  are several slapi_search_internal_get_entry() calls that
> return a copy of Slapi_Entry *e that is never released by
> slapi_entry_free(). Here are the proposed changes :
> --- /tmp/fedora-ds-base-cvs/ldap/servers/plugins/memberof/memberof.c
>  2008-02-19 07:04:56.000000000 +0100
> +++ /tmp/memberof-patched.c     2008-03-23 22:13:00.000000000 +0100
> @@ -1019,6 +1019,7 @@
>         }
>
>  bail:
> +     slapi_entry_free(e);
>         return rc;
>  }
>
> @@ -1310,6 +1311,7 @@
>         }
>
>         slapi_sdn_free(&sdn);
> +      slapi_entry_free(group_e);
>         return rc;
>  }
>
> @@ -1826,6 +1828,8 @@
>
>  bail:
>         slapi_ch_free_string(&filter_str);
> +      slapi_entry_free(group_e);
> +      slapi_entry_free(opto_e);
>
>         slapi_log_error( SLAPI_LOG_TRACE, MEMBEROF_PLUGIN_SUBSYSTEM,
>                 "<-- memberof_is_legit_member\n" );
>
> §2. I don't know whether the arrays pre_array and post_array in
> memberofd_replace_list() function should be freed. I think they should
> because they are allocated by slapi_ch_malloc(), but i'm not sure and
> i don't know how i should free them - i am not a specialist of the
> plugin API. Anyway, apparently this part of code is never used by our
> group management applications so i don't have a memory leak caused by
> this function.
>
> §3. If we make MODRDN on an INDIRECT group the original indirect group
> DN is deleted from memberof but the renamed indirect group DN is not
> added. It may be fixed by running every once in a while the memberOf
> fixup task BUT in this particular case the attribute will never be
> fixed - because of the problem in §4 :
>
> §4. I propose to delete all the memberOf attribute values at the
> beginning of the fix thread. Otherwise if we have in the entry a
> "memberOf" attribute value equal to a DN of a direct group,  the
> memeberOf fix task (the function memberof_fix_memberof_callback())
> will NEVER add the indirect groupsDNs that depend on the
> abovementioned direct group, so this thread is not really a FULL FIX
> thread :) Here are the proposed changes to avoid it:
> --- /tmp/fedora-ds-base-cvs/ldap/servers/plugins/memberof/memberof.c
>  2008-02-19 07:04:56.000000000 +0100
> +++ /tmp/memberof-patched.c     2008-03-23 22:13:00.000000000 +0100
> @@ -2006,6 +2010,7 @@
>  /* memberof_fix_memberof_callback()
>   * Add initial and/or fix up broken group list in entry
>   *
> + * 0. Delete all the memberOf attribute values
>   * 1. Make sure direct membership groups are in the entry
>   * 2. Add all groups that current group list allows through nested membership
>   * 3. Trim groups that have no relationship to entry
> @@ -2016,6 +2021,9 @@
>         char *dn = slapi_entry_get_dn(e);
>         memberof_add_groups data = {dn, dn};
>
> +       /* step 0. */
> +       slapi_entry_attr_delete(e, MEMBEROF_ATTR);
> +
>         /* step 1. and step 2. */
>         rc = memberof_call_foreach_dn(0, dn, MEMBEROF_GROUP_ATTR,
>                 memberof_add_groups_search_callback, &data);
>
> §5. After the code changes proposed in "§1" i still have ~600 bytes
> memory increase per 5000 modifications (2500 DEL & 2500 ADDs to group
> membership, the memory increases mainly at DEL operations). I don't
> know whether it is due to connection management in slapd code or to
> the plug-in itself but it is a much more acceptable value for me than
> 100Mb :)
>
> §6. #define MEMBEROF_GROUP_ATTR_TYPE "uid" is declared but never used
> in the plug-in code...
>
> Thanks once more for this plug-in!
>   
Thank you for the information Andrey.  I'm currently doing some cleanup 
on the memberOf plug-in around the implementation of the cleanup task.  
Once I am finished with that work, I'll look into the issues that you 
raised.

We are working on making the memberOf plug-in more robust, as it's 
currently in a sort of "alpha" stage as you've noticed.  If you are 
interested in helping with this effort (or just following it), take a 
look at the design document for this plug-in on our wiki 
(http://directory.fedoraproject.org/wiki/MemberOf_Plugin).

Thanks again!
-NGK


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/389-devel/attachments/20080324/4b0865c7/attachment.bin 


More information about the 389-devel mailing list