#47958 Memory leak in password admin if the admin entry does not exist
Closed: Fixed None Opened 4 years ago by mreynolds.

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)

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 6ee9a1bd3aa5014aff3b8b07a032c35a1c66d2e2
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 ce0cda2bed8611e845931fd99ac40ba428455be3

f7fcb52..0d6f6ca 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 0d6f6ca269912e41a248c283fdb8929e11120605

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 d9274e23f8132c2624413915d3e2e040d48bf152

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.2.11.33

2 years ago

Login to comment on this ticket.

Metadata