Hide Forgot
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/47623 ==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==
check https://bugzilla.redhat.com/show_bug.cgi?id=1044219 for steps
Created attachment 922568 [details] valgrind.out Output of valgrind running 389-ds-base-1.2.11.15-38.el6.x86_64
Hi Rich, I ran the simple paged tests under valgrind, looks like there are no mentions of pagedresults_parse_control_value in the valgrind log. Could you please review the output just to be sure there are no related leaks? And then I'll move the state of the bug to VERIFIED. Thanks!
Hi Viktor, I reviewed your valgrind output (Rich is on PTO this week). The output contains just memories allocated for the server initialization. So, very clean. Thank you for your thorough testing!
Thank you, Noriko! Marking this bug as VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1385.html