Bug 816168
| Summary: | memory leak: def_urlpre is not freed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | David Spurek <dspurek> | ||||
| Component: | openldap | Assignee: | Jan Vcelak <jvcelak> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Ondrej Moriš <omoris> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6.3 | CC: | dspurek, ebenes, jsynacek, jvcelak, mfranc, omoris, syeghiay, tsmetana | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| 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 07:32:19 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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 |
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