December 2017 - openldap-bugs

by balaret＠gmail.com

Full_Name: Sergey Z Version: LMDB_0.9.19 OS: Android URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2620:119:5001:2242:9215:2763:ff1b:ae35) Hey guys, We are using LMDB 0.9.19 in our Android project and sometimes we are getting SIGBUS in mdb_page_touch(). We can't reproduce this issue on our side but we have plenty of crash reports from our users (about 400 daily): SIGBUS libLMDBAndroid.so.mdb_page_touch ( mdb .c :2412) libLMDBAndroid.so.mdb_page_search ( mdb .c :5610) libLMDBAndroid.so.mdb_freelist_save ( mdb .c :3128) libLMDBAndroid.so.mdb_txn_commit ( mdb .c :3606) This is probably a platform specific issue because 95% of crashes happened on Android 7.0. I would greatly appreciate if you help to shed a light on this - any ideas what might goes wrong or what might cause such an issue. Thank you, Sergey

5 years, 9 months

1
0
0 / 0

Re: (ITS#8783) LMDB on network share path is inconsistent after put data

by hyc＠symas.com

serg.brester(a)sebres.de wrote: > Full_Name: Sergey Brester > Version: all, also latest master 4d5e2d2a2ac38b9d56b6ba73187c325024718167 > OS: windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.154.98.131) > > > If I save many data into LMDB file placed in network share, only the latest key > is really in the database after reopen. The docs explicitly state not to use LMDB with remote filesystems. http://www.lmdb.tech/doc/ Closing 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/

5 years, 9 months

1
0
0 / 0

(ITS#8783) LMDB on network share path is inconsistent after put data

by serg.brester＠sebres.de

Full_Name: Sergey Brester Version: all, also latest master 4d5e2d2a2ac38b9d56b6ba73187c325024718167 OS: windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.154.98.131) If I save many data into LMDB file placed in network share, only the latest key is really in the database after reopen. Tested single threaded (1 process, 1 thread). No matter which flags supplied to mdb_env_open... So repeateable writing of 10 keys (total 960 times) should result in: Target-state: 10 keys { "some-key-0": "951", "some-key-1": "952", "some-key-2": "953", "some-key-3": "954", "some-key-4": "955", "some-key-5": "956", "some-key-6": "957", "some-key-7": "958", "some-key-8": "959", "some-key-9": "960" } After reopen of database you'll see: Actual-state: 1 key { "some-key-9": "960" } Doing the same on local drive works fine and actual state is equal target state.

5 years, 9 months

1
0
0 / 0

Re: (ITS#8782) Memory leak in ldap_cancel

by hyc＠symas.com

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... > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

5 years, 10 months

1
0
0 / 0

(ITS#8782) Memory leak in ldap_cancel

by cheimes＠redhat.com

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...

5 years, 10 months

1
0
0 / 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl

by mkp37215＠gmail.com

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.

5 years, 10 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2017