Bug 807363
Summary: | openldap libraries leak memory when following referrals | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Jakub Hrozek <jhrozek> | |
Component: | openldap | Assignee: | Jan Vcelak <jvcelak> | |
Status: | CLOSED ERRATA | QA Contact: | David Spurek <dspurek> | |
Severity: | medium | Docs Contact: | ||
Priority: | medium | |||
Version: | 6.2 | CC: | ddumas, dpal, ebenes, jsynacek, omoris, tsmetana | |
Target Milestone: | rc | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | openldap-2.4.23-22.el6 | Doc Type: | Bug Fix | |
Doc Text: |
- remote LDAP server responds with referral to a client query, referral chasing is enabled in the library
- library leaks memory
- upstream patch applied
- the library no longer causes memory leak when chasing a referral
|
Story Points: | --- | |
Clone Of: | ||||
: | 859016 (view as bug list) | Environment: | ||
Last Closed: | 2012-06-20 07:32:11 UTC | Type: | --- | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 859016 |
Description
Jakub Hrozek
2012-03-27 15:30:33 UTC
I was also able to reproduce on F-16 with openldap-2.4.26-6. Would you like me to test on some newer release, too? (In reply to comment #1) > I was also able to reproduce on F-16 with openldap-2.4.26-6. Would you like me > to test on some newer release, too? Not necessary. It seems that this part of the code was not changed. Jakub originally sent me this backtrace, it looks like another leak: ==13700== 987,424 (4,720 direct, 982,704 indirect) bytes in 59 blocks are definitely lost in loss record 564 of 564 ==13700== at 0x40053B3: calloc (vg_replace_malloc.c:467) ==13700== by 0xCBBD00: ber_memcalloc_x (in /lib/liblber-2.4.so.2.5.6) ==13700== by 0x12249F: ldap_send_server_request (in /lib/libldap-2.4.so.2.5.6) ==13700== by 0x123323: ldap_chase_v3referrals (in /lib/libldap-2.4.so.2.5.6) ==13700== by 0x10D4EB: ldap_result (in /lib/libldap-2.4.so.2.5.6) ==13700== by 0x485E262: ??? (in /usr/lib/sssd/libsss_ldap.so.1.0.0) ==13700== by 0xB74262: ??? (in /usr/lib/libtevent.so.0.9.8) ==13700== by 0xB70F17: _tevent_loop_once (in /usr/lib/libtevent.so.0.9.8) ==13700== by 0xB70FAE: ??? (in /usr/lib/libtevent.so.0.9.8) ==13700== by 0xB70C88: _tevent_loop_wait (in /usr/lib/libtevent.so.0.9.8) ==13700== by 0x8080D1C: server_loop (in /usr/libexec/sssd/sssd_be) ==13700== by 0x8055BB8: main (in /usr/libexec/sssd/sssd_be) I'm not sure if this is caused by a bug in OpenLDAP or by not freeing some result in SSSD. I will investigate. (In reply to comment #4) > Jakub originally sent me this backtrace, it looks like another leak: > > ==13700== 987,424 (4,720 direct, 982,704 indirect) bytes in 59 blocks are > definitely lost in loss record 564 of 564 > ==13700== at 0x40053B3: calloc (vg_replace_malloc.c:467) > ==13700== by 0xCBBD00: ber_memcalloc_x (in /lib/liblber-2.4.so.2.5.6) > ==13700== by 0x12249F: ldap_send_server_request (in > /lib/libldap-2.4.so.2.5.6) > ==13700== by 0x123323: ldap_chase_v3referrals (in /lib/libldap-2.4.so.2.5.6) > ==13700== by 0x10D4EB: ldap_result (in /lib/libldap-2.4.so.2.5.6) > ==13700== by 0x485E262: ??? (in /usr/lib/sssd/libsss_ldap.so.1.0.0) > ==13700== by 0xB74262: ??? (in /usr/lib/libtevent.so.0.9.8) > ==13700== by 0xB70F17: _tevent_loop_once (in /usr/lib/libtevent.so.0.9.8) > ==13700== by 0xB70FAE: ??? (in /usr/lib/libtevent.so.0.9.8) > ==13700== by 0xB70C88: _tevent_loop_wait (in /usr/lib/libtevent.so.0.9.8) > ==13700== by 0x8080D1C: server_loop (in /usr/libexec/sssd/sssd_be) > ==13700== by 0x8055BB8: main (in /usr/libexec/sssd/sssd_be) > Yes this original leak came from the customer who was using Active Directory. The leak I included in the opening comment was what I reproduces with 389DS. *** Bug 808064 has been marked as a duplicate of this bug. *** Upstream report: http://www.openldap.org/its/index.cgi?findid=6744 Upstream fix (applies cleanly): http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=518dd3a You are right, I've got a patch for this leak. The test packages you gave me fix the memory leak while following referrals. Can we get it into 6.3? Fixed in openldap-2.4.23-22.el6 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: - remote LDAP server responds with referral to a client query, referral chasing is enabled in the library - library leaks memory - upstream patch applied - the library no longer causes memory leak when chasing a referral 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 |