There are several memory leaks reported by valgrind in access control evaluation:
==6882== 4 bytes in 1 blocks are definitely lost in loss record 17 of 1,532 ==6882== at 0x4A0881C: malloc (vg_replace_malloc.c:270) ==6882== by 0x390AE853F1: strdup (in /usr/lib64/libc-2.15.so) ==6882== by 0x4C5FD87: slapi_ch_strdup (ch_malloc.c:277) ==6882== by 0x800AAEB: acl__get_attrEval (acl.c:3930) ==6882== by 0x80051E2: acl_access_allowed (acl.c:500) ==6882== by 0x801F736: acl_access_allowed_main (aclplugin.c:383) ==6882== by 0x4CBD5C5: plugin_call_acl_plugin (plugin_acl.c:90) ==6882== by 0x4CBDA98: slapi_access_allowed (plugin_acl.c:237) ==6882== by 0x8EB28B3: sync_feature_allowed (sync_refresh.c:67) ==6882== by 0x8EB29A3: sync_srch_refresh_pre_search (sync_refresh.c:106) ==6882== by 0x4CB9D96: plugin_call_func (plugin.c:1467) ==6882== by 0x4CB9C56: plugin_call_list (plugin.c:1429)
==6882== 12 bytes in 1 blocks are definitely lost in loss record 127 of 1,532 ==6882== at 0x4A0881C: malloc (vg_replace_malloc.c:270) ==6882== by 0x390AE853F1: strdup (in /usr/lib64/libc-2.15.so) ==6882== by 0x4C5FD87: slapi_ch_strdup (ch_malloc.c:277) ==6882== by 0x800A3EF: acl_copyEval_context (acl.c:3717) ==6882== by 0x800514C: acl_access_allowed (acl.c:478) ==6882== by 0x801F736: acl_access_allowed_main (aclplugin.c:383) ==6882== by 0x4CBD5C5: plugin_call_acl_plugin (plugin_acl.c:90) ==6882== by 0x4C82C67: test_filter_access (filterentry.c:1014) ==6882== by 0x4C82865: slapi_vattr_filter_test_ext_internal (filterentry.c:929) ==6882== by 0x4C82484: slapi_vattr_filter_test_ext (filterentry.c:842) ==6882== by 0x4C823BB: slapi_vattr_filter_test (filterentry.c:790) ==6882== by 0x8EB3283: sync_is_entry_in_scope (sync_refresh.c:415
==6882== 31 bytes in 1 blocks are definitely lost in loss record 347 of 1,532 ==6882== at 0x4A0881C: malloc (vg_replace_malloc.c:270) ==6882== by 0x390AE853F1: strdup (in /usr/lib64/libc-2.15.so) ==6882== by 0x4C5FD87: slapi_ch_strdup (ch_malloc.c:277) ==6882== by 0x801A891: acllist_init_scan (acllist.c:637) ==6882== by 0x801F1EA: aclplugin_preop_search (aclplugin.c:167) ==6882== by 0x4CB9D96: plugin_call_func (plugin.c:1467) ==6882== by 0x4CB9C56: plugin_call_list (plugin.c:1429) ==6882== by 0x4CB7F8F: plugin_call_plugins (plugin.c:403) ==6882== by 0x4CAC986: op_shared_search (opshared.c:565) ==6882== by 0x42F30F: do_search (search.c:413) ==6882== by 0x41514C: connection_dispatch_operation (connection.c:677) ==6882== by 0x416CD8: connection_threadmain (connection.c:2482)
and a couple of leaks in ==6882== by 0x80111BA: aclinit_main (aclinit.c:130) but this is only in init and not properly cleaned at shutdown (which is the case for many plugins)
Can you provide the aci's that are causing these leaks? Or are they just the default aci's?
no special acis for the database, there was one specific for the Sync control:
dn: oid=1.3.6.1.4.1.4203.1.9.1.1,cn=features,cn=config objectClass: top objectClass: directoryServerFeature oid: 1.3.6.1.4.1.4203.1.9.1.1 cn: Sync Request Control aci: (targetattr != "aci")(version 3.0; acl "Sync Request Control"; allow( rea d, search ) userdn = "ldap:///all";)
you could enable this feature, but VLV has the same aci, so this could also work
I can not reproduce any leaks. Are there any special steps I need to follow?
The fixes look ok, assuming the things that are now freed were initialized to NULL or set to a malloced value. {{{ dest->acle_numof_attrs = d_slot; dest->acle_attrEval[d_slot].attrEval_name = NULL; }}} Is it possible at this point in the code that dest->acle_attrEval[d_slot].attrEval_name is set? If so, it would need to be freed or it will be overwritten.
revision 0001-Ticket-47519-memory-leaks-in-access-control.patch
Replying to [comment:7 rmeggins]:
These structures are all calloced when initialized, and also I applied your suggestion. New patch attached.
git merge ticket47519 Updating 04b6137..85bc265 Fast-forward ldap/servers/plugins/acl/acl.c | 6 +++--- ldap/servers/plugins/acl/acl_ext.c | 3 +-- ldap/servers/plugins/acl/acllist.c | 5 +++-- 3 files changed, 7 insertions(+), 7 deletions(-)
git push origin master Counting objects: 17, done. Delta compression using up to 4 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 1.02 KiB, done. Total 9 (delta 7), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 04b6137..85bc265 master -> master
commit 85bc265 Author: Mark Reynolds mreynolds@redhat.com Date: Tue Oct 15 16:42:25 2013 -0400
Metadata Update from @lkrispen: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.3 - 10/13 (October)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/856
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.