openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#8782) Memory leak in ldap_cancel
by hyc＠symas.com 04 Dec '17

04 Dec '17

cheimes(a)redhat.com wrote: > Full_Name: Christian Heimes > Version: 2.4.45 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:16b8:6097:b200:c324:8c3d:7869:1a1b) > > > While I was looking for memory leaks in python-ldap, Valgrind detected a memory > leak in ldap_cancel: Thanks for the report. Fixed now in master. > > ==30178== 22 (16 direct, 6 indirect) bytes in 1 blocks are definitely lost in > loss record 27 of 5,810 > ==30178== at 0x4C2FB6B: malloc (vg_replace_malloc.c:299) > ==30178== by 0x14CBD9E4: ber_memalloc_x (memory.c:228) > ==30178== by 0x14CBC940: ber_flatten (io.c:437) > ==30178== by 0x14A81733: ldap_cancel (cancel.c:50) > ==30178== by 0x1485A3BA: l_ldap_cancel (LDAPObject.c:779) > ==30178== by 0x4FC24EF: PyCFunction_Call (in > /usr/lib64/libpython3.6m.so.1.0) > ==30178== by 0x4FF891C: _PyEval_EvalFrameDefault (in > /usr/lib64/libpython3.6m.so.1.0) > ==30178== by 0x4F590B2: ??? (in /usr/lib64/libpython3.6m.so.1.0) > ==30178== by 0x4F8BE10: ??? (in /usr/lib64/libpython3.6m.so.1.0) > ==30178== by 0x4FC933D: ??? (in /usr/lib64/libpython3.6m.so.1.0) > ==30178== by 0x4FF2EC9: _PyEval_EvalFrameDefault (in > /usr/lib64/libpython3.6m.so.1.0) > ==30178== by 0x4F590B2: ??? (in /usr/lib64/libpython3.6m.so.1.0) > > I think the function is missing a call to ber_bvfree(cancelidvalp). > > python-ldap issue: https://github.com/python-ldap/python-ldap/issues/82 > Code: https://github.com/openldap/openldap/blob/master/libraries/libldap/cancel.c… > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8782) Memory leak in ldap_cancel
by cheimes＠redhat.com 04 Dec '17

04 Dec '17

Full_Name: Christian Heimes Version: 2.4.45 OS: Fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:16b8:6097:b200:c324:8c3d:7869:1a1b) While I was looking for memory leaks in python-ldap, Valgrind detected a memory leak in ldap_cancel: ==30178== 22 (16 direct, 6 indirect) bytes in 1 blocks are definitely lost in loss record 27 of 5,810 ==30178== at 0x4C2FB6B: malloc (vg_replace_malloc.c:299) ==30178== by 0x14CBD9E4: ber_memalloc_x (memory.c:228) ==30178== by 0x14CBC940: ber_flatten (io.c:437) ==30178== by 0x14A81733: ldap_cancel (cancel.c:50) ==30178== by 0x1485A3BA: l_ldap_cancel (LDAPObject.c:779) ==30178== by 0x4FC24EF: PyCFunction_Call (in /usr/lib64/libpython3.6m.so.1.0) ==30178== by 0x4FF891C: _PyEval_EvalFrameDefault (in /usr/lib64/libpython3.6m.so.1.0) ==30178== by 0x4F590B2: ??? (in /usr/lib64/libpython3.6m.so.1.0) ==30178== by 0x4F8BE10: ??? (in /usr/lib64/libpython3.6m.so.1.0) ==30178== by 0x4FC933D: ??? (in /usr/lib64/libpython3.6m.so.1.0) ==30178== by 0x4FF2EC9: _PyEval_EvalFrameDefault (in /usr/lib64/libpython3.6m.so.1.0) ==30178== by 0x4F590B2: ??? (in /usr/lib64/libpython3.6m.so.1.0) I think the function is missing a call to ber_bvfree(cancelidvalp). python-ldap issue: https://github.com/python-ldap/python-ldap/issues/82 Code: https://github.com/openldap/openldap/blob/master/libraries/libldap/cancel.c…

1 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by mkp37215＠gmail.com 01 Dec '17

01 Dec '17

I, Maciej Puzio, hereby place the above modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#8781) "connection_read(248): no connection!" on 2.4.44
by mramitsingh85＠gmail.com 30 Nov '17

30 Nov '17

Full_Name: Amit kumar singh Version: 2.4.44 OS: CentOS release 6.9 (Final) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (14.141.104.38) Issue on replication and get below error. Nov 30 17:03:55 host slapd[709]: connection_read(346): no connection! Nov 30 17:03:55 host slapd[709]: connection_read(346): no connection! Nov 30 17:03:55 host[709]: connection_read(362): no connection! I was searching issue and found that fixed ref: ITS#6548 on 2.4.27. But strange thing is that it comes up again in 2.4.44. Not sure If I am correct but need your help to look into it.

1 0

(ITS#8780) Plug a socket leak in ldap_new_connection made by unsuccessful connection attempts
by hguo＠suse.com 30 Nov '17

30 Nov '17

Full_Name: Houzuo Guo Version: master OS: URL: ftp://ftp.openldap.org/incoming/houzuo-guo-171130.patch Submission from: (NULL) (195.135.221.2) In case that ldap connection is attempted on failed URLs prior to establishing a successful connection, the failed connection sockets are never freed. This patch plugs the socket descriptor leak.

1 0

Re: (ITS#8779) slapo-seqmod missing manpage
by hyc＠symas.com 28 Nov '17

28 Nov '17

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.45 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > The seqmod overlay is missing a man page. This should be fixed. > Pretty sure we've discussed this many times before. No. The seqmod overlay is not meant to be executed and used by anyone. It is meant to be a model for overlay authors to read and learn from. Close this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8779) slapo-seqmod missing manpage
by quanah＠openldap.org 27 Nov '17

27 Nov '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) The seqmod overlay is missing a man page. This should be fixed.

1 0

Re: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by hyc＠symas.com 26 Nov '17

26 Nov '17

Markus Junginger wrote: > Thanks for the report. Unfortunately your suggested fix means the rpage > test will always be skipped on read-only cursors, which will break the > rpage tracking if the txn is still alive. > > > Could you maybe explain a bit about rpages? Why does mdb_cursor_close need to > unref pages, but not mdb_cursor_renew? If closing a transaction does not clean > up rpages, I would have expected mdb_cursor_renew would have to do. And why > does setting MDB_VL32 affect rpages in the first place? To my understanding, > MDB_VL32 is about using 64 bits also on 32 bit CPUs, so a differences on page > handling seem surprising at first sight. Think about how LMDB works. LMDB was originally written for use on 64bit CPUs, with 64bit virtual address spaces. It expects to map an entire DB into virtual memory using a single mmap call. Obviously this cannot be done when trying to use a DB larger than 2GB on a machine with only a 32bit virtual address space. When using MDB_VL32 to access a 64bit DB on a 32bit CPU, the DB cannot fit into a single mmap. It must be mapped in chunks, and the chunks must be mapped, unmapped, and remapped on demand. The rpages thus need to be tracked, to know which are currently mapped. None of this rpage tracking exists in the native non-VL32 build because it's completely unnecessary. Also note that the MDB_VL32 feature is not officially released. You're free to use it if you want, but there is no expectation that it is suitable for general use. When you use unreleased features, you're expected to know how to support yourself. When you use LMDB at all, you're expected to know how virtual addresses work. Ideally, you should quit using obsolete 32bit CPUs. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by hyc＠symas.com 26 Nov '17

26 Nov '17

Markus Junginger wrote: > Thanks for your fast response. > >> Thanks for the report. Unfortunately your suggested fix means >> the rpage test will always be skipped on read-only cursors, which >> will break the rpage tracking if the txn is still alive. > > Does that mean it's not trivial to fix and will take some time? Correct. And I'm still on holiday this week, won't be looking deeper into this for a while. > It's a last outstanding issue for a release, so I guess we have to find a > work around until it's properly fixed? Yes. Best is to use mdb_txn_reset/renew instead of txn_abort. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by markus＠greenrobot.de 26 Nov '17

26 Nov '17

--94eb2c123fa4650778055ee78f61 Content-Type: text/plain; charset="UTF-8" > > Thanks for the report. Unfortunately your suggested fix means the rpage > test will always be skipped on read-only cursors, which will break the > rpage tracking if the txn is still alive. Could you maybe explain a bit about rpages? Why does mdb_cursor_close need to unref pages, but not mdb_cursor_renew? If closing a transaction does not clean up rpages, I would have expected mdb_cursor_renew would have to do. And why does setting MDB_VL32 affect rpages in the first place? To my understanding, MDB_VL32 is about using 64 bits also on 32 bit CPUs, so a differences on page handling seem surprising at first sight. Thanks, Markus --94eb2c123fa4650778055ee78f61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= :1px solid rgb(204,204,204);padding-left:1ex">Thanks for the report. Unfort= unately your suggested fix means the rpage test will always be skipped on r= ead-only cursors, which will break the rpage tracking if the txn is still a= live.</blockquote><div><br></div><div>Could you maybe explain a bit about r= pages? Why does=C2=A0<span style=3D"font-size:12.8px">mdb_cursor_close=C2= =A0</span>need to unref pages, but not mdb_cursor_renew? If closing a trans= action does not clean up rpages, I would have expected mdb_cursor_renew wou= ld have to do. And why does setting MDB_VL32 affect rpages in the first pla= ce? To my understanding, MDB_VL32=C2=A0 is about using 64 bits also on 32 b= it CPUs, so a differences on page handling seem surprising at first sight.<= /div><div><br></div><div>Thanks,</div><div>Markus</div><div><br></div></div= ></div></div> --94eb2c123fa4650778055ee78f61--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs