Bug 1816862 - Memory leak in indirect COS
Summary: Memory leak in indirect COS
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: 389-ds-base
Version: 8.2
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: 8.0
Assignee: mreynolds
QA Contact: RHDS QE
Marc Muehlfeld
URL:
Whiteboard:
Depends On:
Blocks: 1827284
TreeView+ depends on / blocked
 
Reported: 2020-03-24 22:06 UTC by mreynolds
Modified: 2020-11-04 03:08 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-1.4.3.8-2.module+el8.3.0+6591+ebfc9766
Doc Type: Bug Fix
Doc Text:
.Directory Server no longer leaks memory when using indirect COS definitions Previously, after processing an indirect Class Of Service (COS) definition, Directory Server leaked memory for each search operation that used an indirect COS definition. With this update, Directory Server frees all internal COS structures associated with the database entry after it has been processed. As a result, the server no longer leaks memory when using indirect COS definitions.
Clone Of:
: 1827284 (view as bug list)
Environment:
Last Closed: 2020-11-04 03:07:52 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 2496 0 None closed Memory leak in COS 2021-01-07 16:24:02 UTC
Red Hat Product Errata RHEA-2020:4695 0 None None None 2020-11-04 03:08:12 UTC

Description mreynolds 2020-03-24 22:06:38 UTC
Description of problem:

=================================================================
==23238==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 960 byte(s) in 30 object(s) allocated from:
    #0 0x7fc6b921ea38 in __interceptor_calloc (/lib64/libasan.so.4+0xdea38)
    #1 0x7fc6b8a38679 in slapi_ch_calloc /home/william/development/389ds/ds/ldap/servers/slapd/ch_malloc.c:180
    #2 0x7fc6b8bfe125 in slapi_valueset_new /home/william/development/389ds/ds/ldap/servers/slapd/valueset.c:446
    #3 0x7fc6b8c03a8c in valueset_dup /home/william/development/389ds/ds/ldap/servers/slapd/valueset.c:1347
    #4 0x7fc6b8c0786c in slapi_vattr_values_get_sp /home/william/development/389ds/ds/ldap/servers/slapd/vattr.c:737
    #5 0x7fc6ab678751 in cos_cache_follow_pointer /home/william/development/389ds/ds/ldap/servers/plugins/cos/cos_cache.c:3387
    #6 0x7fc6ab673856 in cos_cache_query_attr /home/william/development/389ds/ds/ldap/servers/plugins/cos/cos_cache.c:2337
    #7 0x7fc6ab672799 in cos_cache_vattr_types /home/william/development/389ds/ds/ldap/servers/plugins/cos/cos_cache.c:2115
    #8 0x7fc6b8c0bd4b in vattr_call_sp_get_types /home/william/development/389ds/ds/ldap/servers/slapd/vattr.c:1729
    #9 0x7fc6b8c0a105 in slapi_vattr_list_attrs /home/william/development/389ds/ds/ldap/servers/slapd/vattr.c:1277
    #10 0x7fc6b8b866ae in send_all_attrs /home/william/development/389ds/ds/ldap/servers/slapd/result.c:1140
    #11 0x7fc6b8b8922e in send_ldap_search_entry_ext /home/william/development/389ds/ds/ldap/servers/slapd/result.c:1596
    #12 0x7fc6b8b862c6 in send_ldap_search_entry /home/william/development/389ds/ds/ldap/servers/slapd/result.c:1038
    #13 0x7fc6b8b11a52 in iterate /home/william/development/389ds/ds/ldap/servers/slapd/opshared.c:1380
    #14 0x7fc6b8b12f3c in send_results_ext /home/william/development/389ds/ds/ldap/servers/slapd/opshared.c:1611
    #15 0x7fc6b8b0e4ce in op_shared_search /home/william/development/389ds/ds/ldap/servers/slapd/opshared.c:811
    #16 0x472a3f in do_search /home/william/development/389ds/ds/ldap/servers/slapd/search.c:332
    #17 0x4238b7 in connection_dispatch_operation /home/william/development/389ds/ds/ldap/servers/slapd/connection.c:648
    #18 0x429a71 in connection_threadmain /home/william/development/389ds/ds/ldap/servers/slapd/connection.c:1761
    #19 0x7fc6b635a0ea  (/lib64/libnspr4.so+0x290ea)

Direct leak of 64 byte(s) in 4 object(s) allocated from:
    #0 0x7fc6b921e850 in malloc (/lib64/libasan.so.4+0xde850)
    #1 0x7fc6b8a381d2 in slapi_ch_malloc /home/william/development/389ds/ds/ldap/servers/slapd/ch_malloc.c:95
    #2 0x7fc6b8c0cc24 in vattr_add_attrval /home/william/development/389ds/ds/ldap/servers/slapd/vattr.c:1991
    #3 0x7fc6b8c0d20d in vattr_map_entry_build_schema /home/william/development/389ds/ds/ldap/servers/slapd/vattr.c:2055
    #4 0x7fc6b8c0dac8 in vattr_map_entry_new /home/william/development/389ds/ds/ldap/servers/slapd/vattr.c:2166
    #5 0x7fc6b8c0e524 in vattr_map_sp_insert /home/william/development/389ds/ds/ldap/servers/slapd/vattr.c:2322
    #6 0x7fc6b8c0b7b9 in slapi_vattrspi_regattr /home/william/development/389ds/ds/ldap/servers/slapd/vattr.c:1652
    #7 0x7fc6ab66bd24 in cos_dn_defs_cb /home/william/development/389ds/ds/ldap/servers/plugins/cos/cos_cache.c:864
    #8 0x7fc6b8b5337f in internal_srch_entry_callback /home/william/development/389ds/ds/ldap/servers/slapd/plugin_internal_op.c:99
    #9 0x7fc6b8b88bfd in send_ldap_search_entry_ext /home/william/development/389ds/ds/ldap/servers/slapd/result.c:1495
    #10 0x7fc6b8b862c6 in send_ldap_search_entry /home/william/development/389ds/ds/ldap/servers/slapd/result.c:1038
    #11 0x7fc6b8b11a52 in iterate /home/william/development/389ds/ds/ldap/servers/slapd/opshared.c:1380
    #12 0x7fc6b8b12f3c in send_results_ext /home/william/development/389ds/ds/ldap/servers/slapd/opshared.c:1611
    #13 0x7fc6b8b0e4ce in op_shared_search /home/william/development/389ds/ds/ldap/servers/slapd/opshared.c:811
    #14 0x7fc6b8b56280 in search_internal_callback_pb /home/william/development/389ds/ds/ldap/servers/slapd/plugin_internal_op.c:726
    #15 0x7fc6b8b54c38 in slapi_search_internal_callback_pb /home/william/development/389ds/ds/ldap/servers/slapd/plugin_internal_op.c:518
    #16 0x7fc6ab66cf92 in cos_cache_add_dn_defs /home/william/development/389ds/ds/ldap/servers/plugins/cos/cos_cache.c:1057
    #17 0x7fc6ab66a783 in cos_cache_build_definition_list /home/william/development/389ds/ds/ldap/servers/plugins/cos/cos_cache.c:657
    #18 0x7fc6ab669c3d in cos_cache_create_unlock /home/william/development/389ds/ds/ldap/servers/plugins/cos/cos_cache.c:449
    #19 0x7fc6ab66a0d4 in cos_cache_creation_lock /home/william/development/389ds/ds/ldap/servers/plugins/cos/cos_cache.c:577
    #20 0x7fc6ab669a25 in cos_cache_wait_on_change /home/william/development/389ds/ds/ldap/servers/plugins/cos/cos_cache.c:410
    #21 0x7fc6b635a0ea  (/lib64/libnspr4.so+0x290ea)


Can be triggered by ds/dirsrvtests/tests/suites/cos/indirect_cos_test.py


Upstream ticket:

https://pagure.io/389-ds-base/issue/49437

Comment 3 sgouvern 2020-06-04 10:18:38 UTC
With 389-ds-base-1.4.3.8-2.1asan.el8.x86_64 / 389-ds-base-1.4.3.8-2.module+el8.3.0+6591+ebfc9766.x86_64

No memory leaks detected by ASAN when running dirsrvtests/tests/suites/cos/indirect_cos_test.py

Marking as Verified

Comment 6 errata-xmlrpc 2020-11-04 03:07:52 UTC
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 (389-ds:1.4 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:4695


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