openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#9160) Out-of-memory handling issues
by hyc＠symas.com 29 Jan '20

29 Jan '20

ondra(a)openldap.org wrote: > Full_Name: Ondrej Kuznik > Version: re24/master > OS: > URL: > Submission from: (NULL) (212.159.69.225) > > > A look at the code highlights a few places where *alloc responses are used > unchecked. > > The following semantic patch is a good starting point. Currently it lists 87 > sites most of which probably need adjusting. > > --- malloc_check.cocci --- > @@ > expression E, E1; > identifier ch_alloc =~ "^(ch|slap)_.*alloc.*"; > identifier f =~ "(?i).*alloc.*"; > identifier foo; > @@ > > E = > ( > ch_alloc ch_malloc always aborts if it fails, therefore failure checks are not used. > | > entry_alloc> | > attr_alloc > | These rely on ch_malloc, therefore failure checks are not used. > metaconn_alloc > | > asyncmeta_conn_alloc > | > CompAlloc /* component matching has massively bitrotted */ > | > * f > )(...); > ... when != E = E1 > when != E == NULL > when != E != NULL > ( > E->foo > | > E[...] > | > *(E) > ) > --- malloc_check.cocci --- > > Patches coming soon. > > -- -- 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#9160) Out-of-memory handling issues
by ondra＠openldap.org 29 Jan '20

29 Jan '20

Full_Name: Ondrej Kuznik Version: re24/master OS: URL: Submission from: (NULL) (212.159.69.225) A look at the code highlights a few places where *alloc responses are used unchecked. The following semantic patch is a good starting point. Currently it lists 87 sites most of which probably need adjusting. --- malloc_check.cocci --- @@ expression E, E1; identifier ch_alloc =~ "^(ch|slap)_.*alloc.*"; identifier f =~ "(?i).*alloc.*"; identifier foo; @@ E = ( ch_alloc | entry_alloc | attr_alloc | metaconn_alloc | asyncmeta_conn_alloc | CompAlloc /* component matching has massively bitrotted */ | * f )(...); ... when != E = E1 when != E == NULL when != E != NULL ( E->foo | E[...] | *(E) ) --- malloc_check.cocci --- Patches coming soon.

1 0

(ITS#9159) mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792)
by pasumarthivijaykumar＠gmail.com 29 Jan '20

29 Jan '20

Full_Name: Vijay Kumar Version: 2.4.48 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (103.204.96.6) I am not setting any map size for openldap with mdb configuration in windows. It throws me an error as mentioned below 5e315f30 mdb_id2entry_put: mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792) "cn=azrbasisschema.xsd,cn=nl.ciz.awbz.webservice.awbztransformaties.aanvraag_2_io31_transformatie,cn=method sets,o=system,cn=abc,cn=defaultinst,o=abc.net" 5e315f30 conn=1000 op=8 RESULT tag=105 err=80 text=entry store failed 5e315f30 slap_graduate_commit_csn: removing 0000006519FF99A0 20200129103216.169110Z#000000#000#000000 can you please let me know what could be the issue.? I checked the memory used by customer; file system 30GB available out of 200GB, RAM is 24GB. all the way i see suggestions on linux olxDbMaxsize but for windows we dont set that.

1 0

Re: (ITS#9157) return additional error code information when OPT_X_TLS_NEWCTX fails
by shawn.michael.mckinney＠gmail.com 27 Jan '20

27 Jan '20

In one of our test envs, had the path wrong in replication config for = encryption artifacts: *** Conf excerpt: *** syncrepl =E2=80=A6 tls_key=3D/opt/symas/etc/openldap/file-name.pem *** Which gives generic error: *** Log Trace: *** an 27 17:25:17 sapz1a slapd[6203]: slapd starting =E2=80=A6 TLS context initialization failed (-1) Jan 27 17:25:17 hostname slapd[6203]: do_syncrepl: rid=3D031 rc -1 = retrying (4 retries left) *** Would have been helpful for the message to specify which artifact = wasn=E2=80=99t found, the line number of the config, or some other way = of narrowing the problem. =E2=80=94 Shawn

1 0

(ITS#9157) return additional error code information when OPT_X_TLS_NEWCTX fails
by tagrain＠gmail.com 24 Jan '20

24 Jan '20

Full_Name: Thomas Grainger Version: libldap-2.4-2 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.60.6.23) when setting OPT_X_TLS_NEWCTX after an invalid OPT_X_TLS_CACERTFILE libldap returns a generic error code would it be possible to pass the underlying TLS library's error code instead or in addition? https://github.com/python-ldap/python-ldap/issues/55#issuecomment-577831055

1 0

(ITS#9156) latest ppolicy draft support
by ondra＠openldap.org 23 Jan '20

23 Jan '20

Full_Name: Ondrej Kuznik Version: master OS: URL: https://github.com/mistotebe/openldap/tree/ppolicy10 Submission from: (NULL) (212.159.69.225) There have been a few iterations of the ppolicy behera draft and it would be useful to support (some) of the documented features. The following are coming: - pwdGraceExpiry - pwdMaxLength - pwdStartTime and pwdEndTime - pwdMinDelay and pwdMaxDelay (as a soft-lockout, contingent with other implementations based on an informal survey during latest LDAPCon) - pwdMaxIdle (and moving the relevant parts of lastbind overlay into slapd code as it is a shared dependency of a few things now) - the ability to store per-policy arguments to check_password() - updates/fixes to the draft that should have been identified before some of the above were proposed (mostly typos and ASN.1 schema updates)

1 0

Re: (ITS#9155) LMDB: List of spill pages leaks after transaction
by hyc＠symas.com 23 Jan '20

23 Jan '20

babayants.alexander(a)gmail.com wrote: > Full_Name: Alexander Babayants > Version: LMDB 0.9.24 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (188.170.78.53) > > > Hi! > > ASAN shows that the list of spill pages is not freed after transaction: Thanks for the report. Fixed now in mdb.master and mdb.RE/0.9 > ================================================================= > ==test==13046==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 20971376 byte(s) in 1 object(s) allocated from: > #0 0x4bcbb2 in realloc (test+0x4bcbb2) > #1 0x7f067ef5ed59 in mdb_midl_grow liblmdb/src/midl.c:135:8 > #2 0x7f067ef5ec83 in mdb_midl_append liblmdb/src/midl.c:162:7 > #3 0x7f067ef4456b in mdb_page_spill liblmdb/src/mdb.c:2077:13 > #4 0x7f067ef3960b in mdb_cursor_put liblmdb/src/mdb.c:6640:14 > #5 0x7f067ef5106c in mdb_put liblmdb/src/mdb.c:9027:7 > #6 0x4ec674 in main test.c:28:14 > #7 0x7f067b46d544 in __libc_start_main (/lib64/libc.so.6+0x22544) > > SUMMARY: AddressSanitizer: 20971376 byte(s) leaked in 1 allocation(s). > > Reproducible on LMDB 0.9.24 with the following code (anything doing > long write transaction will trigger this): > #include "lmdb.h" > > int main(int argc,char * argv[]) > { > int rc; > MDB_env *env; > MDB_dbi dbi; > MDB_val key, data; > MDB_txn *txn; > int kval; > char sval[1024] = {0}; // fine to fill with zeroes > > rc = mdb_env_create(&env); > rc = mdb_env_set_mapsize(env, 10ULL * 1024 * 1024 * 1024); // 10 GiB > rc = mdb_env_open(env, "./testdb", 0, 0664); > rc = mdb_txn_begin(env, NULL, 0, &txn); > rc = mdb_dbi_open(txn, NULL, 0, &dbi); > > key.mv_size = sizeof(int); > key.mv_data = &kval; > data.mv_size = sizeof(sval); > data.mv_data = sval; > > for (kval = 0; kval < 100'000'000; ++kval) { > rc = mdb_put(txn, dbi, &key, &data, 0); > } > rc = mdb_txn_commit(txn); > > mdb_dbi_close(env, dbi); > mdb_env_close(env); > return 0; > } > >>From my point of view the leak looks benign (=does not lead to > database corruption or such), but I didn't dive deep enough in LMDB > internals to be completely certain about that. > > Regards, > Alexander Babayants. > > -- -- 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#9126) add: pwdChangedTime leads to seg fault
by ondra＠mistotebe.net 23 Jan '20

23 Jan '20

On Mon, Jan 13, 2020 at 09:35:18PM +0000, michael(a)stroeder.com wrote: > This still happens with current RE24 snapshot. > > Is more information needed to address this? Hi, had a look at it and a proposed patch is in a branch in my GitHub repo: https://github.com/mistotebe/openldap/tree/its9126 Let me know if this fixes the issue for you. As far as I have been able to figure out, the database content generated by ppolicy until now was inconsistent with the schema (normalised value was missing) and existing values will still cause the crash to happen. A fix is to replace the affected values or export/reload the database. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#9155) LMDB: List of spill pages leaks after transaction
by babayants.alexander＠gmail.com 22 Jan '20

22 Jan '20

Full_Name: Alexander Babayants Version: LMDB 0.9.24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.170.78.53) Hi! ASAN shows that the list of spill pages is not freed after transaction: ================================================================= ==test==13046==ERROR: LeakSanitizer: detected memory leaks Direct leak of 20971376 byte(s) in 1 object(s) allocated from: #0 0x4bcbb2 in realloc (test+0x4bcbb2) #1 0x7f067ef5ed59 in mdb_midl_grow liblmdb/src/midl.c:135:8 #2 0x7f067ef5ec83 in mdb_midl_append liblmdb/src/midl.c:162:7 #3 0x7f067ef4456b in mdb_page_spill liblmdb/src/mdb.c:2077:13 #4 0x7f067ef3960b in mdb_cursor_put liblmdb/src/mdb.c:6640:14 #5 0x7f067ef5106c in mdb_put liblmdb/src/mdb.c:9027:7 #6 0x4ec674 in main test.c:28:14 #7 0x7f067b46d544 in __libc_start_main (/lib64/libc.so.6+0x22544) SUMMARY: AddressSanitizer: 20971376 byte(s) leaked in 1 allocation(s). Reproducible on LMDB 0.9.24 with the following code (anything doing long write transaction will trigger this): #include "lmdb.h" int main(int argc,char * argv[]) { int rc; MDB_env *env; MDB_dbi dbi; MDB_val key, data; MDB_txn *txn; int kval; char sval[1024] = {0}; // fine to fill with zeroes rc = mdb_env_create(&env); rc = mdb_env_set_mapsize(env, 10ULL * 1024 * 1024 * 1024); // 10 GiB rc = mdb_env_open(env, "./testdb", 0, 0664); rc = mdb_txn_begin(env, NULL, 0, &txn); rc = mdb_dbi_open(txn, NULL, 0, &dbi); key.mv_size = sizeof(int); key.mv_data = &kval; data.mv_size = sizeof(sval); data.mv_data = sval; for (kval = 0; kval < 100'000'000; ++kval) { rc = mdb_put(txn, dbi, &key, &data, 0); } rc = mdb_txn_commit(txn); mdb_dbi_close(env, dbi); mdb_env_close(env); return 0; } >From my point of view the leak looks benign (=does not lead to database corruption or such), but I didn't dive deep enough in LMDB internals to be completely certain about that. Regards, Alexander Babayants.

1 0

Re: (ITS#9154) RFE: Number of entries in MDB database in cn=monitor
by michael＠stroeder.com 18 Jan '20

18 Jan '20

On 1/18/20 1:54 PM, Howard Chu wrote: > michael(a)stroeder.com wrote: >> The number of entries could be added there as attribute 'olmMDBEntries' or >> similar. > > Added in git master Great! Thank you. Any chance to see it in RE24? At least the back-port patch seems to work smoothly in my local test environment. Ciao, Michael.

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