Bug 816168 - memory leak: def_urlpre is not freed
memory leak: def_urlpre is not freed
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openldap (Show other bugs)
6.3
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Jan Vcelak
Ondrej Moriš
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-25 08:01 EDT by David Spurek
Modified: 2015-03-02 00:26 EST (History)
8 users (show)

See Also:
Fixed In Version: openldap-2.4.23-26.el6
Doc Type: Bug Fix
Doc Text:
- utility from openldap-clients package called without specifying url - memory leak presents - applied upstream patch - the memory leak no longer presents
Story Points: ---
Clone Of:
: 816244 (view as bug list)
Environment:
Last Closed: 2012-06-20 03:32:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
reproduce test (1.87 KB, application/x-gzip)
2012-04-25 08:01 EDT, David Spurek
no flags Details

  None (edit)
Description David Spurek 2012-04-25 08:01:03 EDT
Created attachment 580143 [details]
reproduce test

Description of problem:
glibc leak memory when following openldap referrals on s390x.
I consult this problem with jvcelak and he think that problem is in glibc.

Actual output of relevant part reproduce test:
==5511== Memcheck, a memory error detector
==5511== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==5511== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==5511== Command: ldapsearch -x -b dc=redhat -C
==5511==
==5511== Conditional jump or move depends on uninitialised value(s)
==5511==    at 0x4466B9C: tsearch (tsearch.c:177)
==5511==    by 0x448105F: __nss_lookup_function (nsswitch.c:301)
==5511==    by 0x444CB8B: gaih_inet (getaddrinfo.c:829)
==5511==    by 0x4450359: getaddrinfo (getaddrinfo.c:2358)
==5511==    by 0x40694DB: ldap_connect_to_host (os-ip.c:600)
==5511==    by 0x4050F33: ldap_int_open_connection (open.c:348)
==5511==    by 0x406682D: ldap_new_connection (request.c:425)
==5511==    by 0x4050E65: ldap_open_defconn (open.c:41)
==5511==    by 0x40677E5: ldap_send_initial_request (request.c:106)
==5511==    by 0x405BD87: ldap_sasl_bind (sasl.c:148)
==5511==    by 0x8000B571: tool_bind (common.c:1439)
==5511==    by 0x80007D2B: main (ldapsearch.c:902)
==5511==
# 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
==5511==
==5511== HEAP SUMMARY:
==5511==     in use at exit: 14 bytes in 1 blocks
==5511==   total heap usage: 249 allocs, 248 frees, 72,117 bytes allocated
==5511==
==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)
==5511==
==5511== LEAK SUMMARY:
==5511==    definitely lost: 0 bytes in 0 blocks
==5511==    indirectly lost: 0 bytes in 0 blocks
==5511==      possibly lost: 0 bytes in 0 blocks
==5511==    still reachable: 14 bytes in 1 blocks
==5511==         suppressed: 0 bytes in 0 blocks
==5511==
==5511== For counts of detected and suppressed errors, rerun with: -v
==5511== Use --track-origins=yes to see where uninitialised values come from
==5511== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
:: [   PASS   ] :: Running 'valgrind --leak-check=full --show-reachable=yes ldapsearch -x -b "dc=redhat" -C 2>&1'

Version-Release number of selected component (if applicable):
glibc-2.12-1.80.el6.s390x

How reproducible:
always

Steps to Reproduce:
1. you can install debuginfo-install openldap if you want
2. run runtest.sh from attachement
  
Actual results:
At valgrind output
still reachable: 14 bytes in 1 blocks

Expected results:
no leak
Comment 1 Jan Vcelak 2012-04-25 10:23:34 EDT
It seems that the leak presents even without following the referral.

Btw, getaddrinfo() has matching freeaddrinfo().
Comment 2 Jeff Law 2012-04-25 11:38:40 EDT
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.
Comment 3 Jan Vcelak 2012-04-30 14:28:46 EDT
Upstream fix for this issue:
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=e0adc1aa
Comment 10 Jan Vcelak 2012-05-07 14:17:03 EDT
    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
Comment 11 Ondrej Moriš 2012-05-10 09:26:35 EDT
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?
Comment 13 Ondrej Moriš 2012-05-10 09:51:49 EDT
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?
Comment 14 Miroslav Franc 2012-05-10 09:58:59 EDT
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.
Comment 16 errata-xmlrpc 2012-06-20 03:32:19 EDT
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

Note You need to log in before you can comment on or make changes to this bug.