#47623 fix memleak caused by 47347
Closed: wontfix Opened by rmeggins.

==24307== 672 bytes in 4 blocks are definitely lost in loss record 1,264 of 1,456
==24307== at 0x4A0577B: calloc (vg_replace_malloc.c:593)
==24307== by 0x3A334238DC: PR_NewLock (ptsynch.c:142)
==24307== by 0x4CAA8D0: pagedresults_parse_control_value (pagedresults.c:134)
==24307== by 0x4CA825B: op_shared_search (opshared.c:464)
==24307== by 0x42E515: do_search (search.c:355)
==24307== by 0x414B63: connection_dispatch_operation (connection.c:622)
==24307== by 0x416469: connection_threadmain (connection.c:2339)
==24307== by 0x3A33429995: _pt_root (ptthread.c:204)
==24307== by 0x3A244079D0: start_thread (pthread_create.c:301)
==24307== by 0x3A23CE8B6C: clone (clone.S:115)
==24307==


To ssh://git.fedorahosted.org/git/389/ds.git
b5622fb..1ad3604 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 1ad3604b8bfbd5c2a3c4ca8f55b8690a2098f3df
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Dec 9 17:00:32 2013 -0700
63e919f..8968e07 389-ds-base-1.3.0 -> 389-ds-base-1.3.0
commit 8968e078caacf1021a11c19546c448a4b65db098
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Dec 9 17:00:32 2013 -0700
490360f..8a2c666 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit 8a2c666df491b7c8666f8a70a5038b35c43fbc3b
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Dec 9 17:00:32 2013 -0700
58fca2c..65c5155 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 65c51555c0ecc94c5d93f09124168697ba1db6b3
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Dec 9 17:00:32 2013 -0700
4ae7645..98ccb60 master -> master
commit 98ccb602058270e97a3702ae2b81c17635af8d27
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Dec 9 17:00:32 2013 -0700

Hi Rich,

Just a question as I am unsure to understand when 'pr_mutex' should be allocated.

In pagedresults_parse_control_value without cookie, we receive a new page result control on the current connection. We are looking for room in 'pr_list' to store it. If there is no room left, we allocate more (actually we double) and return an index for the first slot in new space . Else we just return an index to a free slot.

'pr_mutex' lock is allocated only for the returned index. That means that when we double the space, only the first slot has an initialized 'pr_mutex'. My understanding is that next time we enter this function, the returned index may not have a 'pr_mutex'.

0001-Ticket-47623-fix-memleak-caused-by-47347.patch
0001-Ticket-47623-fix-memleak-caused-by-47347.patch

This is good to me. ack

To ssh://git.fedorahosted.org/git/389/ds.git
1ad3604..1eb281a 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 1eb281a8a1c5d6c1a22c198a23a8ba7b65991d77
Author: Rich Megginson rmeggins@redhat.com
Date: Tue Dec 10 08:08:35 2013 -0700
8968e07..75ed4b3 389-ds-base-1.3.0 -> 389-ds-base-1.3.0
commit 75ed4b36722eeff8dc2d6aad0cf5e32dc474c3a7
Author: Rich Megginson rmeggins@redhat.com
Date: Tue Dec 10 08:08:35 2013 -0700
6de4616..5c649dd 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit 5c649ddacd1d2c11b6e922b29472094b780c2a0e
Author: Rich Megginson rmeggins@redhat.com
Date: Tue Dec 10 08:08:35 2013 -0700
1214168..5d3ae5f 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 5d3ae5f709964cd7dfb73b631a22389223f5ef25
Author: Rich Megginson rmeggins@redhat.com
Date: Tue Dec 10 08:08:35 2013 -0700
67a0764..0d4849d master -> master
commit 0d4849dd7551347f0e24ac1027f4d0501084dcf3
Author: Rich Megginson rmeggins@redhat.com
Date: Tue Dec 10 08:08:35 2013 -0700

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1044218

Metadata Update from @rmeggins:
- Issue assigned to rmeggins
- Issue set to the milestone: 1.2.11.26

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/960

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

Metadata