If the entry defined for passwordAdminDN does not exist memory is leaked:
==5617== 8 bytes in 1 blocks are definitely lost in loss record 136 of 1,958 ==5617== at 0x4C291D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5617== by 0x4E85656: slapi_ch_calloc (ch_malloc.c:243) ==5617== by 0x4EEF450: search_internal_pb (plugin_internal_op.c:671) ==5617== by 0x4EEF1E0: slapi_search_internal_pb (plugin_internal_op.c:574) ==5617== by 0x4EF86E5: pw_get_admin_users (pw.c:1563) ==5617== by 0x4EF9814: new_passwdPolicy (pw.c:1955) ==5617== by 0x4ED2E8F: op_shared_allow_pw_change (modify.c:1240) ==5617== by 0x4ED0C4D: do_modify (modify.c:375) ==5617== by 0x4161FE: connection_dispatch_operation (connection.c:660) ==5617== by 0x418166: connection_threadmain (connection.c:2534) ==5617== by 0x718FE3A: ??? (in /usr/lib64/libnspr4.so) ==5617== by 0x77CEEE4: start_thread (in /usr/lib64/libpthread-2.18.so) ==5617== by 0x7AD8B8C: clone (in /usr/lib64/libc-2.18.so) ==5617== ==5617== 16 bytes in 2 blocks are definitely lost in loss record 405 of 1,958 ==5617== at 0x4C291D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5617== by 0x4E85656: slapi_ch_calloc (ch_malloc.c:243) ==5617== by 0x4EEF450: search_internal_pb (plugin_internal_op.c:671) ==5617== by 0x4EEF1E0: slapi_search_internal_pb (plugin_internal_op.c:574) ==5617== by 0x4EF86E5: pw_get_admin_users (pw.c:1563) ==5617== by 0x4EF9814: new_passwdPolicy (pw.c:1955) ==5617== by 0x4EF9FB1: slapi_check_account_lock (pw.c:2203) ==5617== by 0x411618: do_bind (bind.c:732) ==5617== by 0x416154: connection_dispatch_operation (connection.c:635) ==5617== by 0x418166: connection_threadmain (connection.c:2534) ==5617== by 0x718FE3A: ??? (in /usr/lib64/libnspr4.so) ==5617== by 0x77CEEE4: start_thread (in /usr/lib64/libpthread-2.18.so) ==5617== by 0x7AD8B8C: clone (in /usr/lib64/libc-2.18.so)
attachment 0001-Ticket-47958-Memory-leak-in-password-admin-if-the-ad.patch
ack
If this is a SCOPE_BASE level search, why do you need a search filter?
Replying to [comment:2 rmeggins]:
ack If this is a SCOPE_BASE level search, why do you need a search filter?
We need to verify if the base dn(aka passwordAdminDN) is a group or not. We use the filter to do this. If it's not a group, no entries returned, and the dn is considered a single user entry. Otherwise it's a group, and we need to gather its members.
c6e1074..6ee9a1b master -> master commit 6ee9a1b Author: Mark Reynolds mreynolds@redhat.com Date: Mon Nov 17 09:46:33 2014 -0500
99bace9..ce0cda2 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit ce0cda2
f7fcb52..0d6f6ca 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit 0d6f6ca
65d455f..972396d 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit 972396da9cf92d67e5ff597854d62c089b93ae9d
4fb2902..d9274e2 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit d9274e2
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.2.11.33
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/1289
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.