RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 917543 - Memory leak in libdb-4.7.so, used by openldap
Summary: Memory leak in libdb-4.7.so, used by openldap
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openldap
Version: 6.4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Matus Honek
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1139309
TreeView+ depends on / blocked
 
Reported: 2013-03-04 10:25 UTC by David Spurek
Modified: 2016-08-08 13:19 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1139309 (view as bug list)
Environment:
Last Closed: 2016-08-08 13:19:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description David Spurek 2013-03-04 10:25:38 UTC 
Description of problem:
Memory leak in libdb-4.7.so, used by openldap

Version-Release number of selected component (if applicable):
db4-4.7.25-17.el6
openldap-2.4.23-31.el6

How reproducible:
always

Steps to Reproduce:
1.run reproducer script
2.
3.
  
Actual results:
some definitely lost leaks found

Expected results:
no leaks


Additional info:

==23876== Memcheck, a memory error detector
==23876== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==23876== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==23876== Command: /usr/sbin/slapd -u ldap -h ldap://127.0.0.1:3890 -f slapd-master.conf
==23876== Parent PID: 23430
==23876== 
==23876== 
==23876== HEAP SUMMARY:
==23876==     in use at exit: 410,816 bytes in 7,512 blocks
==23876==   total heap usage: 12,536 allocs, 5,024 frees, 905,054 bytes allocated
==23876== 
==23876== LEAK SUMMARY:
==23876==    definitely lost: 27 bytes in 1 blocks
==23876==    indirectly lost: 0 bytes in 0 blocks
==23876==      possibly lost: 0 bytes in 0 blocks
==23876==    still reachable: 410,789 bytes in 7,511 blocks
==23876==         suppressed: 0 bytes in 0 blocks
==23876== Rerun with --leak-check=full to see details of leaked memory
==23876== 
==23876== For counts of detected and suppressed errors, rerun with: -v
==23876== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 36 from 9)
==23876== could not unlink /tmp/vgdb-pipe-from-vgdb-to-23876-by-root-on-rhel64
==23876== could not unlink /tmp/vgdb-pipe-to-vgdb-from-23876-by-root-on-rhel64
==23876== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-23876-by-root-on-rhel64
==23878== Thread 3:
==23878== Conditional jump or move depends on uninitialised value(s)
==23878==    at 0x514FDC8: ??? (in /lib64/libdb-4.7.so)
==23878==    by 0x5150BA8: __log_put (in /lib64/libdb-4.7.so)
==23878==    by 0x5106E68: __db_addrem_log (in /lib64/libdb-4.7.so)
==23878==    by 0x5114147: __db_pitem (in /lib64/libdb-4.7.so)
==23878==    by 0x506B5FA: ??? (in /lib64/libdb-4.7.so)
==23878==    by 0x506CC5B: __bam_iitem (in /lib64/libdb-4.7.so)
==23878==    by 0x5067237: ??? (in /lib64/libdb-4.7.so)
==23878==    by 0x5110A82: __dbc_put (in /lib64/libdb-4.7.so)
==23878==    by 0x5115FC0: __dbc_put_pp (in /lib64/libdb-4.7.so)
==23878==    by 0x20B9F6: bdb_idl_insert_key (in /usr/sbin/slapd)
==23878==    by 0x205E96: bdb_dn2id_add (in /usr/sbin/slapd)
==23878==    by 0x1FD37B: bdb_add (in /usr/sbin/slapd)
==23878== 
==23878== Syscall param pwrite64(buf) points to uninitialised byte(s)
==23878==    at 0x6A33EC3: ??? (in /lib64/libpthread-2.12.so)
==23878==    by 0x5165120: __os_io (in /lib64/libdb-4.7.so)
==23878==    by 0x514EB04: ??? (in /lib64/libdb-4.7.so)
==23878==    by 0x514F7C7: __log_flush_int (in /lib64/libdb-4.7.so)
==23878==    by 0x5151024: __log_put (in /lib64/libdb-4.7.so)
==23878==    by 0x5170257: __txn_regop_log (in /lib64/libdb-4.7.so)
==23878==    by 0x516CF22: __txn_commit (in /lib64/libdb-4.7.so)
==23878==    by 0x516CFAE: ??? (in /lib64/libdb-4.7.so)
==23878==    by 0x1FDA31: bdb_add (in /usr/sbin/slapd)
==23878==    by 0x1BE976: overlay_op_walk (in /usr/sbin/slapd)
==23878==    by 0x1BF3CA: ??? (in /usr/sbin/slapd)
==23878==    by 0x15A38F: fe_op_add (in /usr/sbin/slapd)
==23878==  Address 0x40a8f9c is not stack'd, malloc'd or (recently) free'd
==23878== 
==23878== Conditional jump or move depends on uninitialised value(s)
==23878==    at 0x514FDC8: ??? (in /lib64/libdb-4.7.so)
==23878==    by 0x5150BA8: __log_put (in /lib64/libdb-4.7.so)
==23878==    by 0x508A198: __bam_split_log (in /lib64/libdb-4.7.so)
==23878==    by 0x5079468: __bam_split (in /lib64/libdb-4.7.so)
==23878==    by 0x5067306: ??? (in /lib64/libdb-4.7.so)
==23878==    by 0x5110A82: __dbc_put (in /lib64/libdb-4.7.so)
==23878==    by 0x510283B: __db_put (in /lib64/libdb-4.7.so)
==23878==    by 0x5117632: __db_put_pp (in /lib64/libdb-4.7.so)
==23878==    by 0x205BBB: bdb_dn2id_add (in /usr/sbin/slapd)
==23878==    by 0x1FD37B: bdb_add (in /usr/sbin/slapd)
==23878==    by 0x1BE976: overlay_op_walk (in /usr/sbin/slapd)
==23878==    by 0x1BF3CA: ??? (in /usr/sbin/slapd)
==23878== 
==23878== Thread 5:
==23878== Syscall param pwrite64(buf) points to uninitialised byte(s)
==23878==    at 0x6A33EC3: ??? (in /lib64/libpthread-2.12.so)
==23878==    by 0x5165120: __os_io (in /lib64/libdb-4.7.so)
==23878==    by 0x51537A3: ??? (in /lib64/libdb-4.7.so)
==23878==    by 0x5153A04: __memp_bhwrite (in /lib64/libdb-4.7.so)
==23878==    by 0x515275D: __memp_alloc (in /lib64/libdb-4.7.so)
==23878==    by 0x51544C2: __memp_fget (in /lib64/libdb-4.7.so)
==23878==    by 0x5075D84: __bam_search (in /lib64/libdb-4.7.so)
==23878==    by 0x50648F5: ??? (in /lib64/libdb-4.7.so)
==23878==    by 0x50650A6: ??? (in /lib64/libdb-4.7.so)
==23878==    by 0x510D97D: __dbc_get (in /lib64/libdb-4.7.so)
==23878==    by 0x511691C: __dbc_get_pp (in /lib64/libdb-4.7.so)
==23878==    by 0x209664: bdb_id2entry (in /usr/sbin/slapd)
==23878==  Address 0x407b680 is not stack'd, malloc'd or (recently) free'd
==23878== 
==23878== 
==23878== HEAP SUMMARY:
==23878==     in use at exit: 138,555 bytes in 3,345 blocks
==23878==   total heap usage: 1,483,253 allocs, 1,479,908 frees, 453,643,587 bytes allocated
==23878== 
==23878== LEAK SUMMARY:
==23878==    definitely lost: 130,507 bytes in 3,260 blocks
==23878==    indirectly lost: 0 bytes in 0 blocks
==23878==      possibly lost: 0 bytes in 0 blocks
==23878==    still reachable: 8,048 bytes in 85 blocks
==23878==         suppressed: 0 bytes in 0 blocks
==23878== Rerun with --leak-check=full to see details of leaked memory
==23878== 
==23878== For counts of detected and suppressed errors, rerun with: -v
==23878== Use --track-origins=yes to see where uninitialised values come from
==23878== ERROR SUMMARY: 10 errors from 4 contexts (suppressed: 36 from 9)
Comment 1 Jan Staněk 2013-05-29 13:00:17 UTC 
When tested in current RHEL6 (same versions of the packages), valgrind reports some still-reachable leaks directly in /usr/sbin/slapd, and none definitely lost leaks.

It seems to me that this bug is fixed in current RHEL6.
Comment 2 RHEL Program Management 2013-10-13 23:53:23 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 4 Patrik Kis 2016-06-01 11:23:09 UTC 
The test case for this bug still report some memory leaks. Can it be reviewed? If it is not in db4, please forward the bug to the right component.

openldap-2.4.40-12.el6.x86_64
db4-4.7.25-20.el6_7.x86_64

Valgrind log for the master slapd:

==12061== Memcheck, a memory error detector
==12061== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==12061== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==12061== Command: /usr/sbin/slapd -u ldap -h ldap://127.0.0.1:3890 -f slapd-master.conf
==12061== Parent PID: 11470
==12061== 
==12061== 
==12061== HEAP SUMMARY:
==12061==     in use at exit: 438,183 bytes in 8,582 blocks
==12061==   total heap usage: 15,138 allocs, 6,556 frees, 1,284,001 bytes allocated
==12061== 
==12061== LEAK SUMMARY:
==12061==    definitely lost: 27 bytes in 1 blocks
==12061==    indirectly lost: 0 bytes in 0 blocks
==12061==      possibly lost: 0 bytes in 0 blocks
==12061==    still reachable: 438,156 bytes in 8,581 blocks
==12061==         suppressed: 0 bytes in 0 blocks
==12061== Rerun with --leak-check=full to see details of leaked memory
==12061== 
==12061== For counts of detected and suppressed errors, rerun with: -v
==12061== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 18 from 9)
==12061== could not unlink /tmp/vgdb-pipe-from-vgdb-to-12061-by-root-on-qeos-130.lab.eng.rdu2.redhat.com
==12061== could not unlink /tmp/vgdb-pipe-to-vgdb-from-12061-by-root-on-qeos-130.lab.eng.rdu2.redhat.com
==12061== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-12061-by-root-on-qeos-130.lab.eng.rdu2.redhat.com
==12063== Thread 4:
==12063== Conditional jump or move depends on uninitialised value(s)
==12063==    at 0x55B8DA8: __log_putr (log_put.c:731)
==12063==    by 0x55B9B88: __log_put (log_put.c:463)
==12063==    by 0x556FE68: __db_addrem_log (db_auto.c:257)
==12063==    by 0x557D147: __db_pitem (db_dup.c:130)
==12063==    by 0x54D45FA: __bam_ovput (bt_put.c:915)
==12063==    by 0x54D5C5B: __bam_iitem (bt_put.c:861)
==12063==    by 0x54D0237: __bamc_put (bt_cursor.c:1960)
==12063==    by 0x5579A82: __dbc_put (db_cam.c:1520)
==12063==    by 0x557EFC0: __dbc_put_pp (db_iface.c:2456)
==12063==    by 0x22A486: bdb_idl_insert_key (idl.c:874)
==12063==    by 0x2248C6: bdb_dn2id_add (dn2id.c:99)
==12063==    by 0x21BEBF: bdb_add (add.c:385)
==12063== 
==12063== Syscall param pwrite64(buf) points to uninitialised byte(s)
==12063==    at 0x6EB21A3: ??? (syscall-template.S:82)
==12063==    by 0x55CE200: __os_io (os_rw.c:92)
==12063==    by 0x55B7AE4: __log_write (log_put.c:1226)
==12063==    by 0x55B87A7: __log_flush_int (log_put.c:1009)
==12063==    by 0x55BA004: __log_put (log_put.c:495)
==12063==    by 0x55D9337: __txn_regop_log (txn_auto.c:236)
==12063==    by 0x55D6002: __txn_commit (txn.c:684)
==12063==    by 0x55D608E: __txn_commit_pp (txn.c:539)
==12063==    by 0x21C512: bdb_add (add.c:486)
==12063==    by 0x1C2456: overlay_op_walk (backover.c:671)
==12063==    by 0x1C2EB3: over_op_func (backover.c:723)
==12063==    by 0x15B0BF: fe_op_add (add.c:334)
==12063==  Address 0x40a7f9c is not stack'd, malloc'd or (recently) free'd
==12063== 
==12063== Thread 3:
==12063== Conditional jump or move depends on uninitialised value(s)
==12063==    at 0x55B8DA8: __log_putr (log_put.c:731)
==12063==    by 0x55B9B88: __log_put (log_put.c:463)
==12063==    by 0x54F3198: __bam_split_log (btree_auto.c:303)
==12063==    by 0x54E2468: __bam_split (bt_split.c:403)
==12063==    by 0x54D0306: __bamc_put (bt_cursor.c:2007)
==12063==    by 0x5579A82: __dbc_put (db_cam.c:1520)
==12063==    by 0x556B83B: __db_put (db_am.c:411)
==12063==    by 0x5580632: __db_put_pp (db_iface.c:1556)
==12063==    by 0x2245EB: bdb_dn2id_add (dn2id.c:64)
==12063==    by 0x21BEBF: bdb_add (add.c:385)
==12063==    by 0x1C2456: overlay_op_walk (backover.c:671)
==12063==    by 0x1C2EB3: over_op_func (backover.c:723)
==12063== 
==12063== Syscall param pwrite64(buf) points to uninitialised byte(s)
==12063==    at 0x6EB21A3: ??? (syscall-template.S:82)
==12063==    by 0x55CE200: __os_io (os_rw.c:92)
==12063==    by 0x55BC783: __memp_pgwrite (mp_bh.c:399)
==12063==    by 0x55BC9E4: __memp_bhwrite (mp_bh.c:168)
==12063==    by 0x55BB73D: __memp_alloc (mp_alloc.c:394)
==12063==    by 0x55BD4A2: __memp_fget (mp_fget.c:575)
==12063==    by 0x54DED84: __bam_search (bt_search.c:513)
==12063==    by 0x54CD8F5: __bamc_search (bt_cursor.c:2501)
==12063==    by 0x54CE0A6: __bamc_get (bt_cursor.c:970)
==12063==    by 0x557697D: __dbc_get (db_cam.c:700)
==12063==    by 0x557F91C: __dbc_get_pp (db_iface.c:2095)
==12063==    by 0x2280A4: bdb_id2entry (id2entry.c:125)
==12063==  Address 0x40858e7 is not stack'd, malloc'd or (recently) free'd
==12063== 
==12063== 
==12063== HEAP SUMMARY:
==12063==     in use at exit: 6,920 bytes in 73 blocks
==12063==   total heap usage: 1,459,293 allocs, 1,459,220 frees, 354,625,080 bytes allocated
==12063== 
==12063== LEAK SUMMARY:
==12063==    definitely lost: 27 bytes in 1 blocks
==12063==    indirectly lost: 0 bytes in 0 blocks
==12063==      possibly lost: 0 bytes in 0 blocks
==12063==    still reachable: 6,893 bytes in 72 blocks
==12063==         suppressed: 0 bytes in 0 blocks
==12063== Rerun with --leak-check=full to see details of leaked memory
==12063== 
==12063== For counts of detected and suppressed errors, rerun with: -v
==12063== Use --track-origins=yes to see where uninitialised values come from
==12063== ERROR SUMMARY: 11 errors from 4 contexts (suppressed: 18 from 9)



Valgrind log for the slave slapd:

==12067== Memcheck, a memory error detector
==12067== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==12067== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==12067== Command: /usr/sbin/slapd -u ldap -h ldap://127.0.0.1:3891 -f slapd-slave.conf
==12067== Parent PID: 11470
==12067== 
==12067== 
==12067== HEAP SUMMARY:
==12067==     in use at exit: 432,551 bytes in 8,497 blocks
==12067==   total heap usage: 15,010 allocs, 6,513 frees, 1,272,024 bytes allocated
==12067== 
==12067== LEAK SUMMARY:
==12067==    definitely lost: 27 bytes in 1 blocks
==12067==    indirectly lost: 0 bytes in 0 blocks
==12067==      possibly lost: 0 bytes in 0 blocks
==12067==    still reachable: 432,524 bytes in 8,496 blocks
==12067==         suppressed: 0 bytes in 0 blocks
==12067== Rerun with --leak-check=full to see details of leaked memory
==12067== 
==12067== For counts of detected and suppressed errors, rerun with: -v
==12067== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 18 from 9)
==12067== could not unlink /tmp/vgdb-pipe-from-vgdb-to-12067-by-root-on-qeos-130.lab.eng.rdu2.redhat.com
==12067== could not unlink /tmp/vgdb-pipe-to-vgdb-from-12067-by-root-on-qeos-130.lab.eng.rdu2.redhat.com
==12067== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-12067-by-root-on-qeos-130.lab.eng.rdu2.redhat.com
==12069== Thread 3:
==12069== Conditional jump or move depends on uninitialised value(s)
==12069==    at 0x55B8DA8: __log_putr (log_put.c:731)
==12069==    by 0x55B9B88: __log_put (log_put.c:463)
==12069==    by 0x556FE68: __db_addrem_log (db_auto.c:257)
==12069==    by 0x557D147: __db_pitem (db_dup.c:130)
==12069==    by 0x54D45FA: __bam_ovput (bt_put.c:915)
==12069==    by 0x54D5C5B: __bam_iitem (bt_put.c:861)
==12069==    by 0x54D0237: __bamc_put (bt_cursor.c:1960)
==12069==    by 0x5579A82: __dbc_put (db_cam.c:1520)
==12069==    by 0x557EFC0: __dbc_put_pp (db_iface.c:2456)
==12069==    by 0x22A486: bdb_idl_insert_key (idl.c:874)
==12069==    by 0x2248C6: bdb_dn2id_add (dn2id.c:99)
==12069==    by 0x21BEBF: bdb_add (add.c:385)
==12069== 
==12069== Syscall param pwrite64(buf) points to uninitialised byte(s)
==12069==    at 0x6EB21A3: ??? (syscall-template.S:82)
==12069==    by 0x55CE200: __os_io (os_rw.c:92)
==12069==    by 0x55B7AE4: __log_write (log_put.c:1226)
==12069==    by 0x55B7CFF: __log_fill (log_put.c:1161)
==12069==    by 0x55B8FC2: __log_putr (log_put.c:771)
==12069==    by 0x55B9B88: __log_put (log_put.c:463)
==12069==    by 0x54F3198: __bam_split_log (btree_auto.c:303)
==12069==    by 0x54E2468: __bam_split (bt_split.c:403)
==12069==    by 0x54D0306: __bamc_put (bt_cursor.c:2007)
==12069==    by 0x5579A82: __dbc_put (db_cam.c:1520)
==12069==    by 0x556B83B: __db_put (db_am.c:411)
==12069==    by 0x5580632: __db_put_pp (db_iface.c:1556)
==12069==  Address 0x40a7f9c is not stack'd, malloc'd or (recently) free'd
==12069== 
==12069== Conditional jump or move depends on uninitialised value(s)
==12069==    at 0x55B8DA8: __log_putr (log_put.c:731)
==12069==    by 0x55B9B88: __log_put (log_put.c:463)
==12069==    by 0x54F3198: __bam_split_log (btree_auto.c:303)
==12069==    by 0x54E2468: __bam_split (bt_split.c:403)
==12069==    by 0x54D0306: __bamc_put (bt_cursor.c:2007)
==12069==    by 0x5579A82: __dbc_put (db_cam.c:1520)
==12069==    by 0x556B83B: __db_put (db_am.c:411)
==12069==    by 0x5580632: __db_put_pp (db_iface.c:1556)
==12069==    by 0x2245EB: bdb_dn2id_add (dn2id.c:64)
==12069==    by 0x21BEBF: bdb_add (add.c:385)
==12069==    by 0x1BAB93: do_syncrep2 (syncrepl.c:2864)
==12069==    by 0x1BE4DC: do_syncrepl (syncrepl.c:1539)
==12069== 
==12069== Syscall param pwrite64(buf) points to uninitialised byte(s)
==12069==    at 0x6EB21A3: ??? (syscall-template.S:82)
==12069==    by 0x55CE200: __os_io (os_rw.c:92)
==12069==    by 0x55B7AE4: __log_write (log_put.c:1226)
==12069==    by 0x55B87A7: __log_flush_int (log_put.c:1009)
==12069==    by 0x55BA004: __log_put (log_put.c:495)
==12069==    by 0x55D9337: __txn_regop_log (txn_auto.c:236)
==12069==    by 0x55D6002: __txn_commit (txn.c:684)
==12069==    by 0x55D608E: __txn_commit_pp (txn.c:539)
==12069==    by 0x21C512: bdb_add (add.c:486)
==12069==    by 0x1BAB93: do_syncrep2 (syncrepl.c:2864)
==12069==    by 0x1BE4DC: do_syncrepl (syncrepl.c:1539)
==12069==    by 0x4E42CE7: ldap_int_thread_pool_wrapper (tpool.c:688)
==12069==  Address 0x40a43f7 is not stack'd, malloc'd or (recently) free'd
==12069== 
==12069== Thread 1:
==12069== Syscall param pwrite64(buf) points to uninitialised byte(s)
==12069==    at 0x6EB21A3: ??? (syscall-template.S:82)
==12069==    by 0x55CE200: __os_io (os_rw.c:92)
==12069==    by 0x55BC783: __memp_pgwrite (mp_bh.c:399)
==12069==    by 0x55BC9E4: __memp_bhwrite (mp_bh.c:168)
==12069==    by 0x55CAA6B: __memp_sync_int (mp_sync.c:553)
==12069==    by 0x556A599: __db_sync (db_am.c:577)
==12069==    by 0x5568F69: __db_refresh (db.c:820)
==12069==    by 0x5569150: __db_close (db.c:695)
==12069==    by 0x5582AEF: __db_close_pp (db_iface.c:253)
==12069==    by 0x1CC849: bdb_db_close (init.c:624)
==12069==    by 0x161552: backend_shutdown (backend.c:376)
==12069==    by 0x1379B9: main (main.c:1022)
==12069==  Address 0x407a680 is not stack'd, malloc'd or (recently) free'd
==12069== 
==12069== 
==12069== HEAP SUMMARY:
==12069==     in use at exit: 6,908 bytes in 75 blocks
==12069==   total heap usage: 279,779 allocs, 279,704 frees, 69,210,127 bytes allocated
==12069== 
==12069== LEAK SUMMARY:
==12069==    definitely lost: 59 bytes in 5 blocks
==12069==    indirectly lost: 0 bytes in 0 blocks
==12069==      possibly lost: 0 bytes in 0 blocks
==12069==    still reachable: 6,849 bytes in 70 blocks
==12069==         suppressed: 0 bytes in 0 blocks
==12069== Rerun with --leak-check=full to see details of leaked memory
==12069== 
==12069== For counts of detected and suppressed errors, rerun with: -v
==12069== Use --track-origins=yes to see where uninitialised values come from
==12069== ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 18 from 9)
Comment 5 Petr Kubat 2016-07-25 09:52:58 UTC 
Running the testing script with --leak-check=full yields two instances of definitely lost leaks (both originating in openldap), one of which seems to be expected to happen given this comment (tls_m.c:3259):

/* will leak one time */
char *noforkenvvar = PL_strdup( "NSS_STRICT_NOFORK=DISABLED"

The other leak happens over here:

==6626== 32 bytes in 4 blocks are definitely lost in loss record 31 of 65
==6626==    at 0x4C28A2E: malloc (vg_replace_malloc.c:270)
==6626==    by 0x509102B: ber_memalloc_x (memory.c:228)
==6626==    by 0x509144F: ber_str2bv_x (memory.c:555)
==6626==    by 0x1C52A1: slap_compose_sync_cookie (ldapsync.c:59)
==6626==    by 0x1BED50: do_syncrepl (syncrepl.c:726)
==6626==    by 0x4E42CE7: ldap_int_thread_pool_wrapper (tpool.c:688)
==6626==    by 0x6EAAAA0: start_thread (pthread_create.c:301)
==6626==    by 0xA2C16FF: ???

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