It seems that the leak presents even without following the referral.

Btw, getaddrinfo() has matching freeaddrinfo().

The memory leak is in ldap itself.  If you look at the valgrind summary information it tells you where the memory was allocated:

==5511== 14 bytes in 1 blocks are still reachable in loss record 1 of 1
==5511==    at 0x402C3CC: malloc (vg_replace_malloc.c:236)
==5511==    by 0x80007AC5: main (ldapsearch.c:814)

If we look at ldapsearch.c from openldap-2.4.23 (rhel 6.3) we find the following at line 814:

        def_urlpre = malloc( sizeof("file:////") + strlen(def_tmpdir) );

And if you read the code, def_urlpre is never free'd.


There is an issue here that needs further investigation, specifically the valgrind warning:

==5511== Conditional jump or move depends on uninitialised value(s)

This could be a problem in glibc, openldap or even a false positive. 

I'm going to reassign the memory leak back to openldap since it's clearly an openldap issue.  I'm going to create a clone to track the jump/move depends on uninitialized value problem which I'll assign to glibc for further analysis.

Upstream fix for this issue:
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=e0adc1aa

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
- utility from openldap-clients package called without specifying url
- memory leak presents
- applied upstream patch
- the memory leak no longer presents

Jan, using referrals I still see some error - leaks are resolved, but...

# valgrind --leak-check=full ldapsearch -x -b "dc=redhat" -C 
==9536== Memcheck, a memory error detector
==9536== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==9536== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==9536== Command: ldapsearch -x -b dc=redhat -C
==9536== 
==9536== Conditional jump or move depends on uninitialised value(s)
==9536==    at 0x4463C78: tsearch (in /lib64/libc-2.12.so)
==9536==    by 0x447E087: __nss_lookup_function (in /lib64/libc-2.12.so)
==9536==    by 0x444A4F7: gaih_inet (in /lib64/libc-2.12.so)
==9536==    by 0x444D435: getaddrinfo (in /lib64/libc-2.12.so)
==9536==    by 0x40694DB: ldap_connect_to_host (in /lib64/libldap-2.4.so.2.5.6)
==9536==    by 0x4050F33: ldap_int_open_connection (in /lib64/libldap-2.4.so.2.5.6)
==9536==    by 0x406682D: ldap_new_connection (in /lib64/libldap-2.4.so.2.5.6)
==9536==    by 0x4050E65: ldap_open_defconn (in /lib64/libldap-2.4.so.2.5.6)
==9536==    by 0x40677E5: ldap_send_initial_request (in /lib64/libldap-2.4.so.2.5.6)
==9536==    by 0x405BD87: ldap_sasl_bind (in /lib64/libldap-2.4.so.2.5.6)
==9536==    by 0x8000B5B9: ??? (in /usr/bin/ldapsearch)
==9536==    by 0x80007D31: ??? (in /usr/bin/ldapsearch)
==9536== 
# extended LDIF
#
# LDAPv3
# base <dc=redhat> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# redhat
dn: dc=redhat
objectClass: dcObject
objectClass: organization
o: Red Hat
dc: redhat

# Manager, redhat
dn: cn=Manager,dc=redhat
objectClass: organizationalRole
cn: Manager

# foo, redhat
dn: cn=foo,dc=redhat
objectClass: organizationalRole
cn: foo

# search reference
ref: ldap://localhost/dc=fedora??sub

# fedora
dn: dc=fedora
objectClass: dcObject
objectClass: organization
o: Fedora
dc: fedora

# Manager, fedora
dn: cn=Manager,dc=fedora
objectClass: organizationalRole
cn: Manager

# bar, fedora
dn: cn=bar,dc=fedora
objectClass: organizationalRole
cn: bar

# search result
search: 2
result: 0 Success

# numResponses: 8
# numEntries: 6
# numReferences: 1
==9536== 
==9536== HEAP SUMMARY:
==9536==     in use at exit: 0 bytes in 0 blocks
==9536==   total heap usage: 250 allocs, 250 frees, 72,137 bytes allocated
==9536== 
==9536== All heap blocks were freed -- no leaks are possible
==9536== 
==9536== For counts of detected and suppressed errors, rerun with: -v
==9536== Use --track-origins=yes to see where uninitialised values come from
==9536== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)

Is there still some issue?

Ah, I have overlooked it. Well, not it does make sense! Thanks a lot. I see that bug is not proposed for any future RHEL, is this something we should just live with?

I suppose it will be added to default suppression file, but it was just too late for RHEL 6.3 and I don't think anybody cares about RHEL 6.4 yet. Till then you can either live with it or use your own suppression.

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/RHSA-2012-0899.html