Hide Forgot
Description of problem: Please see BZ#717738#c18-20. There is a possible leak in openldap (see below) while using ldapsearch over TLS. It has been suggested that this is a bug in openldap. ==5127== 32 bytes in 1 blocks are definitely lost in loss record 46 of 87 ==5127== at 0x400682F: malloc (vg_replace_malloc.c:236) ==5127== by 0xC13008: PR_Malloc (prmem.c:467) ==5127== by 0xC0FBC1: GrowStuff (prprf.c:1076) ==5127== by 0xC0F5E6: dosprintf (prprf.c:137) ==5127== by 0xC0FA81: PR_vsmprintf (prprf.c:1127) ==5127== by 0xC0FC74: PR_smprintf (prprf.c:1105) ==5127== by 0x551C85: nss_MkConfigString (nssinit.c:205) ==5127== by 0x551D7B: nss_Init (nssinit.c:597) ==5127== by 0x552AD7: NSS_InitContext (nssinit.c:800) ==5127== by 0x4052CCE: tlsm_deferred_ctx_init (tls_m.c:1600) ==5127== by 0xC18FD0: PR_CallOnceWithArg (prinit.c:832) ==5127== by 0x404FCAC: tlsm_session_new (tls_m.c:2308) ==5127== by 0x404DCFB: alloc_handle (tls2.c:296) ==5127== by 0x404DE8B: ldap_int_tls_connect (tls2.c:341) ==5127== by 0x404E111: ldap_int_tls_start (tls2.c:833) ==5127== by 0x404E29B: ldap_start_tls_s (tls2.c:939) ==5127== by 0x8052F52: tool_conn_setup (common.c:1290) ==5127== by 0x804DB80: main (ldapsearch.c:900) Version-Release number of selected component (if applicable): openldap-2.4.23-15.el6 and openldap-2.4.23-16.el6 How reproducible: always
https://bugzilla.redhat.com/show_bug.cgi?id=717738#c20 > > > This is a leak in NSS - please file a bug against nss for this. > > Looks like Openldap is not calling the clear session cache function. > > bob OpenLDAP calls SSL_ClearSessionCache. I have verified that. I believe this is really a NSS bug. Switching the component to "nss".
Since RHEL 6.2 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
The bug description should have included information on how to reproduce the leak. All I can find is the hint in the referenced bug to use ldapsearch -ZZ I've executed valgrind ldapsearch -ZZ on a RHEL 6.4 system, and I get: ==3480== Memcheck, a memory error detector ==3480== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==3480== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==3480== Command: ldapsearch -ZZ ==3480== ldap_start_tls: Can't contact LDAP server (-1) ==3480== ==3480== HEAP SUMMARY: ==3480== in use at exit: 33,155 bytes in 9 blocks ==3480== total heap usage: 97 allocs, 88 frees, 45,021 bytes allocated ==3480== ==3480== LEAK SUMMARY: ==3480== definitely lost: 0 bytes in 0 blocks ==3480== indirectly lost: 0 bytes in 0 blocks ==3480== possibly lost: 0 bytes in 0 blocks ==3480== still reachable: 33,155 bytes in 9 blocks ==3480== suppressed: 0 bytes in 0 blocks ==3480== Rerun with --leak-check=full to see details of leaked memory ==3480== ==3480== For counts of detected and suppressed errors, rerun with: -v ==3480== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 32 from 10) I conclude the leak has been fixed in the meantime, and I'm resolving this bug as WORKSFORME. If you still can reproduce leaks, then please provide steps to reproduce.