==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 1ad3604 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 8a2c666 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 65c5155 Author: Rich Megginson rmeggins@redhat.com Date: Mon Dec 9 17:00:32 2013 -0700 4ae7645..98ccb60 master -> master commit 98ccb60 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 1eb281a 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 5c649dd 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 5d3ae5f Author: Rich Megginson rmeggins@redhat.com Date: Tue Dec 10 08:08:35 2013 -0700 67a0764..0d4849d master -> master commit 0d4849d 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.
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.