==30484== 1,371 bytes in 43 blocks are definitely lost in loss record 12 of 13 ==30484== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==30484== by 0x8258EFB: ber_memalloc_x (memory.c:226) ==30484== by 0x80A743C: ch_malloc (ch_malloc.c:54) ==30484== by 0x81747E5: bdb_entry_get (id2entry.c:421) ==30484== by 0x8104832: overlay_entry_get_ov (backover.c:365) ==30484== by 0x81FF53A: syncprov_matchops (syncprov.c:1151) ==30484== by 0x820175E: syncprov_op_mod (syncprov.c:1870) ==30484== by 0x8104F47: overlay_op_walk (backover.c:660) ==30484== by 0x810517C: over_op_func (backover.c:722) ==30484== by 0x81052AA: over_op_delete (backover.c:774) ==30484== by 0x80FA708: syncrepl_entry (syncrepl.c:2283) ==30484== by 0x80F5AC5: do_syncrep2 (syncrepl.c:877) ==30484== by 0x80F72C2: do_syncrepl (syncrepl.c:1301) ==30484== by 0x8086439: connection_read_thread (connection.c:1218) ==30484== by 0x8222E50: ldap_int_thread_pool_wrapper (tpool.c:663) ==30484== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==30484== by 0x423FDBD: clone (in /lib/libc-2.5.so)
This was the result of a concurrency test while testing MMR. Not sure about how to reproduce it, but I've seen lots of deadlock resolutions, so probably there's some exception we're not handling fine with respect to memory allocation (HEAD as of today).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati wrote:
==30484== 1,371 bytes in 43 blocks are definitely lost in loss record 12 of 13 ==30484== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==30484== by 0x8258EFB: ber_memalloc_x (memory.c:226) ==30484== by 0x80A743C: ch_malloc (ch_malloc.c:54) ==30484== by 0x81747E5: bdb_entry_get (id2entry.c:421)
^^^ well, apparently bdb_entry_get() is malloc'ing a bdb_lock_info that's attached to op_extra, but nobody frees it.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati wrote:
Pierangelo Masarati wrote:
==30484== 1,371 bytes in 43 blocks are definitely lost in loss record 12 of 13 ==30484== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==30484== by 0x8258EFB: ber_memalloc_x (memory.c:226) ==30484== by 0x80A743C: ch_malloc (ch_malloc.c:54) ==30484== by 0x81747E5: bdb_entry_get (id2entry.c:421)
^^^ well, apparently bdb_entry_get() is malloc'ing a bdb_lock_info that's attached to op_extra, but nobody frees it.
Probably a consequence of the uninitialized bli_flag you detected with valgrind. I.e., should also now be fixed in HEAD.
Howard Chu wrote:
Pierangelo Masarati wrote:
Pierangelo Masarati wrote:
==30484== 1,371 bytes in 43 blocks are definitely lost in loss record 12 of 13 ==30484== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==30484== by 0x8258EFB: ber_memalloc_x (memory.c:226) ==30484== by 0x80A743C: ch_malloc (ch_malloc.c:54) ==30484== by 0x81747E5: bdb_entry_get (id2entry.c:421)
^^^ well, apparently bdb_entry_get() is malloc'ing a bdb_lock_info that's attached to op_extra, but nobody frees it.
Probably a consequence of the uninitialized bli_flag you detected with valgrind. I.e., should also now be fixed in HEAD.
Yes, this leak does no longer show up. Thanks, p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
-
Howard Chu -
Pierangelo Masarati